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ABSTRACT 


The Navy Marine Corps Intranet began planning to transition Marine Corps 
aviation eomputer assets to the NMCI network in 2004. Despite the preeeding years of 
transferring other Navy and Marine Corps IT assets, NMCI offered no assuranees that the 
transfer of Marine Corps aviation maintenanee eomputers and systems would transition 
to NMCI without serviee interruption. Marine Corps aviation units use the Naval 
Taetieal Combat Support System (NTCSS) every day in garrison and while deployed to 
doeument and traek maintenanee aetions; it is the mandatory element neeessary to enable 
Marine Corps aviation units to maintain aireraft operational readiness. 

The Marine Requirements Oversight Couneil eoneluded that a proof of eoneept 
would be eondueted to ensure NMCI eomputers would meet the requirements for Marine 
Corps deploying units. Contraet line item number 0004AC (CLIN 4AC) was seleeted as 
the most effective and affordable CLIN from the NMCI products. Marine aviation was 
chosen as the test element since IT connectivity in garrison and while deployed is crucial 
to maintain aircraft readiness. 

This thesis followed the Aviation Proof of Concept (APOC) from its requirements 
phase to final implementation. It started with developmental testing to identify issues in 
relation to transitioning the Marine Corps aviation NTCSS network into NMCI. The 
issues discovered during the development test were brought foreword for the APOC’s 
Test Integration Working Group (TIWG) to analyzed and mitigate. The APOC’s 
operational test used actual Marine aviation units to operate NMCI deployable computers 
in a real-world environment. The thesis concludes with the current APOC status and 
future research. 


V 



THIS PAGE INTENTIONALLY LEET BLANK 


VI 



TABLE OF CONTENTS 


I. INTRODUCTION.I 

A. PURPOSE OF STUDY.2 

B. OVERVIEW OF CHAPTERS.2 

1. Chapter 1.2 

2. Chapter II.2 

3. Chapter III.3 

4. Chapter IV.3 

5. Chapter V.4 

6. Chapter VI.4 

II. OVERVIEW OF NMCI.5 

A. OVERVIEW OF TRANSITIONING TO NMCI.5 

1. NMCI Contract Goals.5 

2. Mission Impact—Issues of Using an Outside Vendor.6 

3. Standardization—NMCI Effects on Configuration 

Management.7 

4. Contract Line Item Numbers (CLINs).8 

5. Service Level Agreements (SLAs).10 

6. Execution Discipline.12 

B. OVERVIEW OF NMCI IN MARINE CORPS AVIATION.13 

1. NMCI’s Goals for USMC Aviation.13 

2. Mission Impact—USMC Aviation Programs Affected hy 

NMCI.14 

3. Standardization—NMCI Effects on Configuration 

Management in Marine Aviation.15 

4. Key Policies and Regulations for USMC Aviation Maintenance 

Programs.15 

C. IMPACT OF NMCI ON USMC AVIATION.15 

1. Mission Impact—Change Management Effects on Marine 

Corps Aviation Operations.15 

2. Standardization—Standardization of IT Assets in Marine 

Corps Aviation Units.16 

3. Key Policies and Regulations—Current Policies and 

Regulations Affected hy the Transition to NMCI.16 

III. AVIATION PROOF OF CONCEPT PRE-ASSESSMENT.17 

A. DEVELOPMENTAL TEST PREPARATIONS.17 

1. Seat Transition.17 

2. Training.18 

3. Network Architecture.19 

4. Test Criteria.20 

B. DEVELOPMENTAL TEST.21 

I. Network Architecture.21 

vii 





































2. Conduct of Test.22 

a. Garrison Phase . 22 

b. Deployed Phase . 23 

c. Return Phase . 24 

C. DEVELOPMENTAL TEST RESULTS.24 

1. Test Criteria Results.24 

2. Test Issues.26 

a. Aviation Applications . 26 

b. Static IP Addresses for NTCSS Printers . 26 

c. DP-17 Van Pad Connectivity . 26 

d. Cross Community of Interest .27 

IV. AVIATION PROOF OF CONCEPT.29 

A. PRE-TEST—AVIATION PROOF OF CONCEPT.29 

1. Network Architecture.33 

2. Aviation Software Applications.37 

3. Seat Transition.38 

4. DP-17 Van Pad Operations.40 

5. NTCSS Printers.42 

6. Cross Community of Interest (X-COI).43 

B. TEST—AVIATION PROOF OF CONCEPT.46 

1. Test Criteria.47 

2. Schedule of Events.47 

3. Training.47 

4. Network Architecture.48 

5. Test—Garrison Phase.50 

6. Test—Deployed Phase.51 

7. Test—Return to Garrison Phase.53 

C. POST-TEST—AVIATION PROOF OF CONCEPT.53 

1. Network Architecture.53 

2. Seat Transition.53 

3. Marine Corps Aviation Issues.54 

a. Aviation Applications . 54 

b. Static IPs for NTCSS Printers .55 

c. DP-17 Van Pad Connectivity .55 

d. X-COI .55 

V. MARINE AVIATION NTCSS SERVER TRANSITION.57 

A. CLIN 27.57 

1. CLIN 27 AG.58 

2. CLIN 27 AG Orders.59 

B. CLIN 27 TRANSITION FOR NTCSS SERVERS.59 

1. Base/Site Preparations.60 

2. CLIN 27 AG NTCSS Transition Schedule.60 

3. CLIN 27 AG NTCSS Transition Issues.60 

C. CLIN 27 AG NTCSS TRANSITION RESULTS.60 


viii 















































VI. SUMMARY AND CONCLUSIONS.61 

A. SUMMARY AND CONCLUSION OF THE APOC.61 

B. MARINE AVIATION TRANSITION ISSUES INTO NMCI.63 

1. Marine Aviation Seat Transition.63 

a. Aviation Applications . 63 

b. NTCSS Printers . 64 

2. DP-17 Van Pad.64 

3. X-COI.65 

4. Marine Aviation NTCSS Servers.66 

C. CURRENT STATUS AND NEXT GENERATION ENTERPRISE 

NETWORK.66 

1. Current Status of Marine Aviation and NMCI.67 

2. The Future of Marine Aviation and NGEN.67 

D. FUTURE RESEARCH.67 

LIST OF REFERENCES.69 

APPENDICES.71 

A. SERVICE LEVEL AGREEMENTS.71 

B. USMC AVIATION MESSAGE.74 

C. APOC TIWG CHARTER.76 

D. APOC PROJECT SCHEDULE.79 

E. USMC AVIATION APPLICATIONS TEMPLATE.86 

F. EDS/USMC MARINE AIR GROUPS.89 

G. MCAF KANEOHE BAY NMCI TRANSITION SCHEMATICS.95 

INITIAL DISTRIBUTION LIST.107 


























THIS PAGE INTENTIONALLY LEET BLANK 


X 



LIST OF FIGURES 


Figure 1. Description of a CLIN 0004AC.10 

Figure 2. NMCI Service Level Agreements.12 

Figure 3. Execution Discipline Decision Meeting Matrix.13 

Figure 4. NTCSS Network Architecture.19 

Figure 5. DP-17 Van pad.27 

Figure 6. MCAF Kaneohe Bay, HI.29 

Figure 7. MCAF Kaneohe Bay Airport Diagram.30 

Figure 8. Marine Aviation NMCI Integration Risk Matrix Post APOC DT.31 

Figure 9. Marine Aviation NMCI Integration Risk and Mitigation Plan Post APOC 

DT.31 

Figure 10. USMC Aviation ED Guidance Matrix.32 

Eigure 11. NTCSS Network Configuration Pre NMCI Transition.34 

Eigure 12. NTCSS Network Configuration Post NMCI Transition.35 

Eigure 13. NTCSS Network Configuration Post NMCI Transition Issues.36 

Eigure 14. NET to CDR Overall Process Plow.39 

Eigure 15. Marine Aviation Seat Transition Risk Matrix Post APOC DT.40 

Eigure 16. NMCI / USMC DP-17 Van pad Agreement Schematic.41 

Eigure 17. OMA - IMA Interface Configurations.45 

Eigure 18. NMCI Network Configuration for MCAP Kaneohe Bay.48 

Eigure 19. Marine Aviation NMCI Integration Risk and Mitigation Matrix Pre APOC ..49 

Eigure 20. APOC Testers.50 

Eigure 21. DP-17 Van Pads APOC Deployed Test Site.51 

Eigure 22. Hangar 101 Deployed Site Diagram.52 

Eigure 23. Proposed USMC Cross COI Solution.65 

























THIS PAGE INTENTIONALLY LEET BLANK 



LIST OF TABLES 


Table 1. 


APOC Test Criteria Results 


,25 




THIS PAGE INTENTIONALLY LEET BLANK 


XIV 



LIST OF ACRONYMS AND ABBREVIATIONS 


AIMD 

Aircraft Intermittent Maintenance Department 

APOC 

Aviation Proof of Concept 

AOR 

Assumption of Responsibility 

ATC 

Authority To Connect 

ATO 

Authority To Operate 

BIO 

Basie Input Output 

BIOS 

Basic Input Output Services 

CDR 

Central Data Repository 

CLIN 

Contraet Line Item Number 

CONUS 

Continental United States 

DAA 

Designated Approving Authority 

DADMS 

Defense Automated Document Management System 

DC AVN 

Deputy Commandant Aviation 

DM 

Decision Meeting 

DNMCI 

Director Navy Marine Corps Intranet 

DON 

Department of the Navy 

DoD 

Department of Defense 

DRPM-NMCI 

Direct Reporting Program Manager NMCI 

DT 

Developmental Test 

DTSB 

Deployable Site Transport Boundary 

DWG 

Deployables Working Group 

EDS 

Electronic Data Systems 

eMp 

eMarketplaee 

GB 

Gigabit 

HQMC 

Headquarters Marine Corps 

HMH 

Helicopter Marine Heavy 

IP 

Internet Protocol 

ISF Tools 

Integrated Solutions Framework Tools 

IT 

Information Teehnology 


XV 



JRB 

LADRA 

MAF 

MALS 

MARCORSYSCOM 

MCEN 

MCOTEA 

MROC 

NAEC 

NAECOMIS 

NAS 

NET 

NETWARCOM 

NGEN 

NIPR 

NMCI 

NTCSS 

OCONUS 

OIMA 

OOMA 

OT 

PUK 

RAP Tool 

RCP 

Seat 

SIPR 

SEA 

SPAWAR 

SSAA 

TCP 

TIWG 


Joint Reserve Base 

Eegacy Applieation Deployment Readiness Aetivity 

Maintenanee Aetion Eorm 

Marine Aviation Logistics Squadron 

Marine Corps Systems Command 

Marine Corps Enterprise Network 

Marine Corps Operational and Testing Activity 

Marine Requirements Oversight Council 

Naval Aviation Logistics Center 

Naval Aviation Logistics Command Management Information 
System 

Naval Air Station 

NMCI Enterprise Tool 

Navy Network Warfare Command 

Next Generation Enterprise Network 

Non-Secure Internet Protocol Router 

Navy Marine Corps Intranet 

Navy Tactical Combat Support Systems 

Outside Continental United States 

Optimized Intermediate Maintenance Activity application 

Optimized Organizational Maintenance Activity application 

Operational Test 

Pack Up Kit 

Requirements To Award Process Tool 
Remote Copy Protocol (Cisco) 

A NMCI desktop or laptop computer 

Secure Internet Protocol Router 

Service Level Agreement 

Space and Naval Warfare Systems Command 

System Security Approval Authority 

Transmission Control Protocol 

Test Integration Working Group 


XVI 



UIC 

Unit ITR 

USMC 

VPN 


Unit Identification Code 

Unit Information Technology Representative 

United States Marine Corps 

Virtual Private Network 


xvii 



THIS PAGE INTENTIONALLY LEET BLANK 



ACKNOWLEDGMENTS 


I would like to acknowledge all of the stakeholders of the Aviation Proof of 
Concept who provided a comprehensive view of a test project from concept to delivery. I 
would like to thank Marine Corps AISD personnel for all of the foresight into developing 
a functional environment for Marine aviation maintenance IT infrastructure into NMCI. 



THIS PAGE INTENTIONALLY LEET BLANK 


XX 



EXECUTIVE SUMMARY 


The Aviation Proof of Concept (APOC) proved that Marine aviation could 
transition and operate on the NMCI network without any prolonged network interruption. 
The APOC Test Integration Working Group was composed of all of the stakeholders that 
had an interest in the operation of Marine aviation’s Naval Tactical Command Support 
System (NTCSS) and the Navy and Marine Corps Intranet (NMCI). The APOC took 
project planning and system engineering to analyze and create a solution in order for 
Marine aviation NTCSS systems to be transitioned in NMCI without affecting Marine 
aviation operational readiness. 

The APOC was a developmental/operational (DT/OT) test project that took the 
issues of Marine aviation maintenance IT systems to determine the requirements for 
transitioning the Marine Corps aviation IT assets into NMCI. The initial DT was a 
discovery phase to determine network functionality of the Marine NTCSS system and the 
rules and regulations related by the ambiguous NMCI contract. The DT produced several 
issues that the APOC TIWG sought to solve or mitigate in order for Marine aviation to 
transition into NMCI and for the APOC operational test to move forward. The OT was 
conducted at Marine Corps Air Facility (MCAF) Kaneohe Bay, Hawaii. This site was 
chosen because the base had Marine aviation and Navy aviation units located on the same 
base. 

The APOC’s first concern was the transition of MCAF Kaneohe Bay into NMCI. 
The transition began with the plan of continuing the transition while the APOC OT 
preceded as planned. The APOC OT was successful in many respects. Marine aviation 
can operate on the NMCI network. Also, Marine aviation software was standardized 
throughout the Marine aviation community. The issue of whether Marine units can use 
NMCI Deployable computers to was positively answered but brought up more issue of 
computer security and computer support. 

The APOC was a success in that it provided processes and procedures for Marine 
aviation and NMCI to follow for the rest of transition phase of Marine aviation units. 
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I. 


INTRODUCTION 


The Navy Marine Corps Intranet (NMCI) is a serviee eontraet between the 
Department of the Navy (DON) and Eleetronie Data Systems Corporation (EDS). The 
eontraet was awarded on 6 Oetober 2000, for a period of seven years with a three-year 
option. The objective is to transfer the majority of the DON information technology 
assets over to the ownership and management of EDS. The Einited States Marine Corps 
(USMC) IT (information technology) assets are included as part of this contract. Navy 
IT assets, specifically Naval Aviation, were the first to be transitioned over to NMCI. 

The Marine Corps Systems Command (MARCORSYSCOM) Navy and Marine Corps 
Intranet (NMCI) program office had taken the lessons learned from the Navy’s transition 
and developed processes to mitigate risks. Despite using these lessons learned, the 
USMC aviation community was reluctant to transition without a proven concept of 
operations. The hurdles our Navy counterparts endured created skepticism for USMC 
aviation users. In addition, there are vast numbers of software programs and operating 
systems that must undergo the scrutiny of change management. One of the last obstacles 
for transitioning USMC IT assets is to ensure that USMC aviation units could transition 
into NMCI without mission impact. These concerns were addressed by the Marine 
Requirements Oversight Council (MROC) that decided a proof of concept was in order to 
prove that USMC aviation units could operate in the NMCI environment. 

The requirements from the USMC aviation community focused mainly on the 
Naval Tactical Combat System Support (NTCSS) suite of applications. The NTCSS 
suite of applications is a collection of aviation maintenance and logistics applications that 
are required in order for any aircraft maintenance action to be processed. The goal of 
transitioning USMC aviation units over to the NMCI environment would follow the 
Execution Discipline milestones established by the Marine Corps NMCI program office. 
However, the transitioning of USMC aviation units brought to the forefront issues that 
had either been neglected or never conceived. 
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The USMC’s NMCI aviation plan included the largest percentage of 
“Deployable” computers, of which almost all USMC aviation seats will be in this 
category. The philosophy of conducting the Aviation Proof of Concept for USMC 
aviation is that it represents the most challenging aspects of transitioning, maintaining, 
and deploying users in and out of NMCI. While the proof of concept will include other 
NMCI Deployable issues, this study will examine only the transitioning of Marine 
Aviation IT assets to NMCI. 

A. PURPOSE OF STUDY 

The purpose of this study is to analyze issues associated with transitioning USMC 
aviation squadrons and aviation logistics squadrons IT assets over to NMCI. The process 
of transitioning government IT assets is explained in “Execution Discipline.” Execution 
Discipline sets the timeline and milestones in order to mitigate the risk in transitioning a 
site and/or users over to NMCI. USMC aviation and aviation logistics units must have 
risk mitigation in place before transitioning their IT assets over to NMCI. This is 
necessary because NTCSS applications are required to conduct day-to-day flight and 
maintenance operations. This study will participate in a pre-assessment to conduct 
developmental testing to identify issues of transitioning Marine aviation units into NMCI. 
The issues identified will then be analyzed by the APOC Test Integration Working Group 
(TIWG). It is this group’s charter to successfully integrate USMC aviation into NMCI. 
The APOC is the test bed to determine whether Marine aviation can successfully 
transition and operate in the NMCI domain. 

B. OVERVIEW OF CHAPTERS 

1. Chapter I 

Chapter I introduces the thesis and explains the purpose of the study. Each 
chapter’s overview is explained as to the chapter’s content. 

2. Chapter II 

This chapter briefly describes the background of the NMCI contract and 
provisions related the issues of transitioning IT assets into NMCI. The constraints of 
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identifying and transitioning IT assets over to NMCFs eontrol are the initial issues with 
whieh a command has to confront in transferring IT assets over to NMCI. Contract Line 
Item Numbers are the products and services that NMCI offers to DON users. These 
products generally involve desktop and laptop computers: upgrades of service and 
hardware performance, and any other additional services. Service Level Agreements are 
the contractual agreements on what an item is to receive in regards to services and 
performance. This is a performance-based contract where the contractor is rewarded or 
disciplined according to performance standards. Execution Discipline is the process that 
governs the NMCI transition milestones. These milestones start with identifying the 
infrastructure requirements of a site to the number of seats to be ordered by a command 
and/or site. 


3. Chapter III 

Chapter III covers the APOC pre-assessment. This is the discovery test phase to 
uncover any unforeseen obstacles in operating the NTCSS applications and/or network 
infrastructure on NMCI network. The pre-assessment will also outline any alternate 
procedures for transitioning aviation seats over to NMCI. This chapter also discusses 
USMC aviations configuration management of aviation software. The Functional Area 
Manager (FAM) is responsible for all USMC aviation applications. These applications 
not only include the NTCSS suite but also any logistical and operational applications 
used by USMC aviation. The chapter will examine the test results and the conclusions 
brought forward by the APOC TIWG. The chapter will conclude with recommendations 
taken by the APOC TIWG in order to execute USMC aviations transition over to NMCI. 

4. Chapter IV 

Chapter IV covers the Aviation Proof of Concept which is the operational test 
conducted at MCAF Kaneohe Bay, HI. It will cover the test preparations conducted by 
the APOC TIWG, the site transition office, and NMCI base operations at Kaneohe Bay, 
HI. The secondary objective for the APOC is to determine the functionality of using 
NMCI seats for USMC deployments. 
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5. Chapter V 

Chapter V provides the plans to transition Marine Corps NTCSS aviation servers 
over to the NMCI domain. The ehapter explains the NMCI contract for CLIN 27 server 
connections and how they will apply to the Marine Corps aviation servers. The chapter 
concludes with an execution plan to transition the Marine Corps NTCSS servers over to 
NMCI. 


6. Chapter VI 

Chapter VI covers the summary and conclusions of the APOC. The chapter 
summarizes the status of the issues identified and how they were or were not resolved. It 
gives a brief view of the next phase of the NMCI contract when it will be re-competed in 
2010. The chapter concludes by discussing follow on research issues for Marine Corps 
aviation computers in the Marine Corps. 


4 



II. OVERVIEW OE NMCI 


This chapter provides a brief overview of sections of the NMCI eontraet that 
influenced the transition into NMCI. The Contract Line Items Numbers and Service 
Level Agreements assoeiated with the NMCI eontraet are the produets and serviees 
within the NMCI eontraet that affect the customers direetly. The issues eneountered in 
transitioning the Navy’s IT assets over to NMCI provided a lessons learned for the 
ereation of the Exeeution Diseipline proeess ereated by the MCSC NMCI program offiee 
transition team and EDS. Exeeution Discipline provided a basie template to transitioning 
U. S. Marine Corps aviation IT assets over to NMCI. The ehapter also diseusses the 
impacts to USMC aviation IT activities due to the transition of IT assets over to NMCI. 

A. OVERVIEW OF TRANSITIONING TO NMCI 
I. NMCI Contract Goals 

The prineipal goal of EDS was to transition and integrate all identified DON 
networks into one single network. This ineludes all Navy’s non-seeure internet protoeol 
router (NIPR) and seeure internet protoeol router (SIPR) networks loeated in the 
Continental United States (CONUS); ^ U. S. Marine Corps CONUS installation’s NIPR 
and SIPR networks; and the Marine Corps installations outside the Continental United 
States (OCONUS).2 The transition ineludes all Marine Corps and Navy’s IT assets that 
have been identified for eutover. The standardization of hardware, software, and 
networks would enable the DON to have a homogeneous network viee the splintered 
systems it possesses. The benefits of integrating the DON network and employing 
eonfiguration management throughout the environment has never been disputed, 
however, IT assets have never been under the eontrol of one entity before. The 
transitioning of the Marine Corps’ and Navy’s IT assets over to EDS brought to the 

1 CONUS - Continental United States - States that reside in the boundaries of North America of the 
United States 

2 OCONUS - Outside Continental United States - Territories, states, and countries that are outside the 
continental United States (i.e., Hawaii, Puerto Rico, and Guam) SIPR and NIPR networks located in the 
Far East. CONUS sites for the USMC are designated to include all forty-eight continental states and 
Hawaii. The Marine Corps defines its OCONUS sites in the Far East as Japan and Okinawa. 
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surface the vast amount of uncorrelated networks, computers, and software programs 
spread throughout the DON. EDS initially attempted to transition the entire Navy 
enterprise wide. This met with miserable results from the lack of coordination between 
the management, the warehouses, installation, and users. The requirements by the DON 
to operate legacy applications resulted in users having two eomputers on their desks, one 
for the legaey network and one for NMCI network. 

Under the current contract EDS is only reimbursed at 85% until a site transitions 
over 50% of its IT assets. EDS has been transitioning assets for the total time of the 
contraet due to the diverse nature of the DON’s IT structure. As of June 2005, EDS had 
yet to transition any USMC site over 50% to NMCI. This miscalculation has resulted in 
prolonged delays in assuming responsibility and eontrol of the DON’s IT assets. Despite 
the transition statistics, in 2005, EDS finally took assumption of responsibility of all U. S. 
Marine Corps IT assets and network management of all assets. An area of responsibility 
(AOR) entails that EDS is responsible for not only NMCI networking issues but must 
also support the operation of USMC legacy networks until transitioned into NMCI. 

2. Mission Impact—Issues of Using an Outside Vendor 

The two big changes to the way users will operate in NMCI. The first change is 
that users do not have administrative rights to their eomputers that they were aecustomed 
to in the past. Most users were able to configure their own eomputers, install new 
software, and do virtually anything else that they wanted to do. After transitioning a 
eomputer over to NMCI, a user loses all of these privileges, even the Unit Information 
Teehnology Representative (Unit ITR). All of the eonfiguration management, network 
serviees, and network seeurity are handled by NMCI while in garrison with oversight by 
the government. Benefits to this architecture are that configuration management is 
established at an enterprise level. This effeets how the Unit ITRs support their 
commands’ routine IT problems while in garrison. Traditionally, a new user would join 
their unit and an account would be created by the Unit ITR. The Unit ITR would also be 
responsible for getting computers repaired, redireeting e-mail, etc. There was a 
significant amount of responsibility plaeed on the Unit ITR for the daily inner workings 
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of a command’s IT services. Now with a serviee provided by a vendor, all of these 
funetions are removed from the Unit ITRs’ eontrol while the computers are attaehed to 
the NMCI network. All trouble ealls are handled by the NMCI help desk. 

The seeond signifieant ehange is the security posture of the NMCI network. The 
seeurity direetives flow down the chain of command from the Department of Defense 
(DoD), DON, Naval Network Warfare Command (NetWarCom), and Marine Corps 
Network Operations & Seeurity Command (MCNOSC) who take direetion from the 
Marine Corps Designated Approving Authority (DAA). The DAA approves all network 
connections where they are granted an Authority To Connect (ATC)^ and an Authority 
To Operate (ATO).^ All systems conneeted to the NMCI network must have an 
approved System Seeurity Approval Authority (SSAA). Software applications are also 
tested and approved by the DAA, NMCI, DRPM, and the MCSC NMCI PM offiee. The 
initial applieations were either designated commereial or a program of record and were 
granted an ATC and ATO on the Marine Corps COI.^ This will help reduce the network 
and software vulnerabilities from users who infeet the network by installing unauthorized 
software. 


3. Standardization—NMCI Effects on Configuration Management 

The Navy and Marine Corps as a whole have been divergent in IT standardization 
for many years but also within eaeh serviee there are differences from different 
eommands and geographical regions. The Marine Corps has three distinet geographieal 
areas; West eoast (southern CA area); East eoast (North Carolina, South Carolina) and 
the Far East (Okinawa, Japan). Eaeh region has its own sehedule for transitioning but 
must also fit into the overall seheme. The problems eneountered in one region could 
possibly be encountered in one or all of the other regions. The need for standardization is 

3 Authority To Connect (ATC) - The DAA approves a system or network to connect to the main 
network. This is granted after the required security measures and documentation have been submitted and 
approved by the DAA. An interim ATO (lATC) can be granted temporarily by the DAA. 

Authority To Operate (ATO) - The DAA approves a system or network to connect to the main 
network. This is granted after the required security measures and documentation have been submitted and 
approved by the DAA. An interim ATC (lATO) can be granted temporarily by the DAA. 

^ Community of Interest (COI) - A shared relation or interest. In this case it relates to all IT 
equipment that is connected to the Marine Corps NMCI network 
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not only for the Marines and for the Navy but it should also include joint standards as 
well. There are many areas of standardization that are going to affect NMCI, but for this 
segment, we will only discuss the top priorities. 

a. Hardware - The hardware is ordered as a certain Contract Line Item Numbers 
(CLIN)^ item. The CLIN’s for hardware are broken down to either desktops or laptops. 
From there the difference in categories depends on the amount of performance in the 
hardware. Depending on a command’s allocated budget for IT, it can upgrade its 
hardware order with additional features or performance. 

b. Software - The basic software load for all NMCI seats is contained in the 
software bundle designated Gold Disk version 2.14. This includes the programs EDS 
requires in order to manage the seat and basic Microsoft Office software. The 
standardization of software on the government side comes from the process of having to 
submit required software for each site so that it can be tested. This process is known as 
Legacy Application Deployment Readiness Activity (LADRA). LADRA testing ensures 
that all required software will operate at a particular site. It is a requirement for each site 
to begin NMCI transition. 

c. Bandwidth - The infrastructure was initially to be replaced with fiber optics 
by NMCI, however, due to the vastness and time this would have taken it was decided to 
only to build infrastructure where it was needed. It is EDS’s responsibility to ensure that 
the infrastructure will support the network at each individual site. This is accomplished 
through site testing of available bandwidth. EDS reserves 20% of the bandwidth for 
surge capacity. 

4. Contract Line Item Numbers (CLINs) 

EDS lists the services and products it provides to users by CLINs. The CLINs 
describe the available types of hardware, software, and services offered by NMCI. These 
CLINs are ordered by CTRs who represent units in ordering the type and quantity of 
seats they will be receiving when their current computer is transitioned over to NMCI. 


^ Contract Line Item Number (CLIN) - A CLIN item is a particular service or product provided by the 
NMCI vendor. For example, a CLIN 0004AC is a non-ruggedized deployable laptop computer. 
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The CLINs are listed on the NMCI Web site. The CLIN 0004AC is the laptop that will 
be used by the USMC aviation eommunity. 


Non-Ruggedized Deployable Portable Seat 


CLIN 0004AC Price: $333.97 per month 


The Non-Ruggedized Deployable Portable (Deployable Portable) seat 
allows for the periodie deployment and use in an expeditionary or field 
environment. Deployable Portable seats shall be eapable of interfaeing 
with IT-21 shipboard networks and the Marine Corps Tactical Network 
(MCTN). 

Reconfiguration to interface with IT-21 or other non-NMCI (e.g., Disembarked) network 
is not the responsibility of the NMCI Information Strike Force. Reconfiguration for return 
and interface with NMCI is a responsibility of the NMCI Information Strike Force. 

The included workplace services can be viewed in the Seat CLIN Services page . The 
current PC hardware and software specifications are available in the Standard 
Seats/Portable Workstation section of the eMarketplace browser . The delivered PC 
configurations may vary from what is listed based upon units available for placement. 

The Deployable Portable Seat CLIN can be upgraded by the following CLINs; 

• CLIN 0007 - High-End Seat Upgrade 

• CLIN 0009AA - Classified Connectivity Upgrade 

• CLIN 0009AC - Switchable Classified (Dual CPU Solution) 

• CLIN 0009AE - Switchable Classified (Dual CPU Solution/White) 

• CLIN 0009AF - Switchable Classified (Dual CPU Solution/Blue) 

• CLIN 0009AG - Switchable Classified (Dual CPU Solution/Portable) 

• CLIN 0009AH - Switchable Classified (Dual CPU Solution/Non-Ruggedized 

Deployable Portable) 



The following specifications depict the hardware and software included in the CLIN. However, the 
delivered PC configurations may vary from what is listed based upon units available for placement. 

Additional CLIN service offering details are available in the Services section of NMCI Homeport. Copy 
and paste the URL http://www.homeport.navy.mil/services/clin/ in a new browser to access the NMCI 
Homeport CLINs. 
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Hardware Specifications 


Software Specifications 


Notebook PC (Weight 4-5 lbs.) 
Pentium M 750 (1.86Ghz) 

1.0GB DDR2-667 SDRAM (1 DIMM) 

40GB hard disk 

CD-RW/DVD Combo Drive 

14.1 XGA active matrix (TFT) display 

Integrated Audio 

Network Interface Card 

CAC Reader 

56K modem 

6 cell primary battery 

Nylon Carrying case 

USB Keyboard 

USB Optical Mouse 

Monitor Stand 

Port Replicator 

17" CRT Monitor 


Windows XP* or 2000 

Internet Explorer and Communicator 

Smart Card Support 

NetMeeting 

Real Player & Windows Media Player 
WinZip 

Antivirus Protection 
PDF Viewer 

TN3270 Client & VT100 Emulation 
Remote Management Software 
Standard Office Automation Software: 
o MS Word 
o MS Excel 
o MS PowerPoint 
o MS Access 
Microsoft Exchange/Outlook 
o Active Directory Driven 
Desktop Management 

o Electronic Records Management 


Figure 1. Description of a CLIN 0004AC^ 


5. Service Level Agreements (SLAs) 

The SLAs* * are agreements between the government and EDS that define the 
metrics for each type of service provided by NMCI in relation to CLINs. Each CEIN 
product has certain SEAs associated with it that define the types of services it is expected 
to receive. Eigure 2 outlines the SLAs in the NMCI contract for a computer while 
attached to the NMCI network. 


SERVICE NAME: END-USER PROBLEM RESOLUTION 
SLA: 101 

Performance Category: End User Problem Resolution 
Increment 1 SLAPC: 101 

SERVICE NAME: NETWORK PROBLEM RESOLUTION 
SLA:102 

Performance Category: Network Problem Resolution 
Increment 1 SLAPC: 102 

SERVICE NAME: END-USER SERVICES 
SLA:103 


^ Figure 1 taken from the NMCI Web site in 2006. (https://www.homeport.navy.mil) 

* Service Level Agreements - SLAs are performance metrics used by the government to measure 
EDS’s performance on the NMCI contract. 
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Performance Category: E-mail Services - User E-mail Availability 
Increment 2 SLAPC: 103.1.1 

Performance Category: E-mail Services - E-Mail End-to-End (Client-Server-Server-Client 
Performance 

Increment 2 SLAPC: 103.1.2 

Performance Category: E-mail Services - E-Mail Server Service Availability 
Increment 1 SLAPC: 103.1.3 

Performance Category: E-mail Services - E-mail Client Responsiveness 
Increment 2 SLAPC: 103.1.4 

Performance Category: Web and Portal Services 
Increment 2 SLAPC: 103.2 

Performance Category: File Share Services - Server Availability 
Increment 1 SLAPC: 103.3.1 

Performance Category: File Share Services - Client Responsiveness 
Increment 1 SLAPC: 103.3.2 

Performance Category: Print Services 
Increment 1 SLAPC: 103.4 

Performance Category: Network PKI Logon Services 
Increment 1 SLAPC: 103.5 

Performance Category: Problem Resolution for Access to Government Applications Increment 1 
SLAPC: 103.6 

Performance Category: RAS Services - Service Availability 
Increment 1 SLAPC: 103.7.1 

Performance Category: RAS Services - Client Responsiveness 
Increment 1 SLAPC: 103.7.2 

Performance Category: Blackberry Services 
Increment 1 SLAPC: 103.8 

SERVICE NAME: HELP DESK 
SLA:104 

Performance Category: Average Speed of Answer - Telephone Calls 
Increment 1 SLAPC: 104.1.1 

Performance Category: Average Speed of Response - Voice Mail/E-mail 
Increment 2 SLAPC: 104.1.2 

Performance Category: Call Abandonment Rate 
Increment 1 SLAPC: 104.2 

Performance Category: First Call Resolution 
Increment 1 SLAPC: 104.3 

SERVICE NAME: MOVE, ADD, CHANGE 
SLA:105 

Performance Category: Move, Add, Change 
Increment 1 SLAPC: 105 

SERVICE NAME: INFORMATION ASSURANCE SERVICES 
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SLA:106 

Performance Category: Security Event Detection 
Increment 1 SLAPC: 106.1 

Performance Category: Security Event Reporting 
Increment 1 SLAPC: 106.2 

N00024-00-D-6000 
Conformed Contract PO0129 

Performance Category: Security Event Response 
Increment 1 SLAPC: 106.3 

Performance Category: Configuration Management 
Increment 1 SLAPC: 106.4 

SERVICE NAME: NMCI INTRANET 
SLA:107 

Performance Category: Availability 
Increment 1 SLAPC: 107.1 

Performance Category: Latency/Packet Loss 
Increment 1 SLAPC: 107.2 

Performance Category: Voice and Video Quality of Service 
Increment 1 SLAPC: 107.3 


Figure 2. NMCI Service Level Agreements^ 

6. Execution Discipline 

The Marine Corps Systems Command’s NMCI PMO used the lessons learned 
from the Navy’s NMCI transition to help avoid costly mistakes and delays. Execution 
Discipline is a process created to avoid the duplication of errors created with the Navy’s 
transition to NMCI. The process was created by the Marine Corps NMCI program office 
and EDS. It establishes milestones to be met in order to facilitate a smooth transition of 
government IT assets over to the control of NMCI. Three decision meetings outline the 
required input and the expected output of each of the meetings. The ED process starts 
once DM1 is deemed successful. DM1 is aimed at the high-level design of the site. It 
identities the requirements of the site to provide to the vendor. DM2s are where the 
detailed design is locked down. This is the most important DM of the three because it 
maps seats to wall plugs, finalizes the rationalized legacy applications list, and sets a site- 
segment transition plan. Eocking down the order negates multiple changes on the 

^ Figure 2 taken from the NMCI Homeport Web site in 2006. (https://www.homeport.navy.mil) 
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customers’ part and allows EDS to concentrate on one order vice many changes. DM3 is 
the milestone that defines whether the site is ready to transition or not. 


Decision Meetino 1 || 

Decision Meetino 2 || 

Decision Meeting 3 k 

Hicn-Level Design | 

DetailM Desicn | 

Cirovet Readiness | 
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Figure 3. Execution Discipline Decision Meeting Matrixi^ 

B. OVERVIEW OF NMCI IN MARINE CORPS AVIATION 
I. NMCI’s Goals for USMC Aviation 

The principal goal still remained to get all U. S. Marine Corps IT assets 
transitioned over to the control of NMCI. The challenges that aviation presents is that the 
hardware and legacy software applications that are to be transitioned are used on a daily 
basis for operations. Any prolonged delay in transitioning assets USMC aviation IT 
assets over to NMCI is unacceptable. The impact of non-functioning computers for 
aviation could result in degraded mission capability and possibly cripple the squadron’s 
maintenance activities. This is the main reason why Marine aviation has delayed 
transition since the aviation information systems are vital for daily operations. Navy 
aviation has provided some proof that NTCSS application will work on NMCI. Navy 

Figure 3 taken from the USMC NMCI PM brief on Execution Discipline. 
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squadrons were some of the first to transition to NMCI. The Navy squadrons were using 
NMCI eomputers but they also had a legaey eomputer next to it beeause the NTCSS 
servers were outside NMCI through two boundaries (B2). The diffieulties that the Navy 
squadrons faced by being the first to transition did nothing to promote the overall 
acceptance of outsourcing IT services to NMCI. 

2. Mission Impact—USMC Aviation Programs Affected by NMCI 

The two types of Marine aviation units affected by transitioning to NMCI: Marine 
Aviation Logistics Squadrons (MATS) and USMC flying squadrons must execute a 
seamless transition. Of all of the issues encountered, the computers used for maintenance 
purposes are the number one concern. A USMC aviation flying squadron can be divided 
into two different areas: maintenance and the squadron’s support shops that include 
operations, logistics, and safety. The maintenance side of an aviation flying unit is the 
prominent user of the NTCSS applications. Marine Aviation Logistics Squadrons 
business is to track, repair, and supply aviation parts to the flying squadrons. A MALS is 
an intermediate maintenance activity (IMA) which supports a Marine Air Group (MAG). 
A MAG consists of several flying units of which can be of different type aircraft. 

SPAWAR PMW-150 is the owner of the NTCSS applications. The NTCSS 
applications are the suite of applications that the maintenance departments of all aviation 
units use in their daily tasks. The NTCSS suite was created by the merger of three 
programs: 

SNAP - Shipboard Non-Tactical Automated Data Processing Program 

MRMS - Maintenance Resource Management System 

NALCOMIS - Naval Aviation Logistics Command Management Information System 
From this, the NTCSS suite consists of four applications: 

R-ADM - Relational Administrative Data Management 

RSupply - Relational Supply 

OMMS-NG - Organizational Maintenance Management System - Next Generation 

NALCOMIS - Naval Aviation Logistics Command Management Information System 
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These are the vital aviation maintenanee applieations that must be validated and 
verified to operate on the NMCI network. 

3. Standardization—NMCI Effects on Configuration Management in 
Marine Aviation 

SPAWAR’s PMW-150 provided eomputers and printers for USMC aviation 
maintenanee funetions. With the NMCI transition, they no longer provide eomputers but 
still provide printers for tactical use. PMW-150 also dictates the network links and IP 
addresses for the NALCOMIS servers. In addition, PMW-150 provides configuration 
management for the NALCOMIS software for both the Marine Corps and Naval aviation 
units. The overall scheme has not changed except now it must be certified and approved 
to be on the NMCI network. 

4. Key Policies and Regulations for USMC Aviation Maintenance 
Programs 

OPNAVISNT 4790.2J is the document that oversees Naval aviation aircraft 
maintenance procedures and processes. PMW-150 and the FAM for Marine Corps 
aviation set the standard and guidelines for using NTCSS suite. 

C. IMPACT OF NMCI ON USMC AVIATION 

I. Mission Impact—Change Management Effects on Marine Corps 
Aviation Operations 

The process of operating and maintaining the NTCSS software, hardware, and 
networks, while in garrison or on deployment has been the responsibility of the USMC’s 
Aviation Information Systems Department. The Marines who are responsible for the 
NTCSS applications possess the same IT skills of any comparable IT organization’s IT 
department. These same personnel who once ensured the NTCSS system was operational 
while in garrison will now only act as observers while in the garrison environment. 
Hardware is supplied by EDS in the form of a CLIN order. In USMC aviations case 
these will be almost exclusively CLIN 0004ACs. Software is also provided by NMCI 
that includes both COTS and GOTS. Seats are ordered with the software bundle the user 
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orders to enable him or her to do their respeetive job. Network eonnectivity is also the 
responsibility of EDS. Therefore, while in garrison, all eonfiguration management issues 
and IT problems are the responsibility of NMCI. 

The other side of the issue is that when the Marine unit deploys outside of NMCI, 
the responsibilities of establishing and maintaining the NTCSS system goes baek to the 
eontrol of AISD. 

2. Standardization—Standardization of IT Assets in Marine Corps 
Aviation Units 

Standardizing the hardware, software, and network eonnections should only 
improve the USMC’s NTCSS posture. The USMC aviation FAM is responsible for all 
aspeets of eonfiguration management in relation to Marine Corps aviation maintenanee. 
The two main standardization features will be: 

• Hardware - This will be the same CLIN ordered by eaeh unit thus 
enabling eomputers to be swapped out or replaee for repair. 

• Software - By loading all of the available NTCSS applieations on the 
eomputer, it ean be used by more than one person to aeeomplish tasks. 
Furthermore, by standardizing the version of all software enterprise wide, 
this enhanees eompatibility between the different squadrons. 

3. Key Policies and Regulations—Current Policies and Regulations 
Affected by the Transition to NMCI 

The overall poliey regarding transitioning USMC IT assets over to NMCI is the 
NMCI eontraet. The eontraet ean be amended by only by the designated eontraeting 
offieer. Other doeuments to faeilitate transition sueh as the Exeeution Diseipline are 
merely guidelines for effeetive proeesses. 
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III. AVIATION PROOF OF CONCEPT PRE-ASSESSMENT 


This chapter covers the Marine Corps Aviation Proof of Coneept developmental 
test eondueted at Camp Pendleton, CA, in January 2005. The development test (DT) ^ 
was eondueted in order to diseover teehnieal and proeedural obstaeles in transitioning 
USMC aviation maintenanee applieations to the NMCI network. The teehnieal issues 
diseovered during the DT would be addressed by the APOC Test TIWG .12 The 
proeedural eheeklist of the Exeeution Diseipline framework was the baseline from whieh 
to apply neeessary ehanges in transitioning USMC aviation IT assets to NMCI. Marine 
Corps Test and Evaluation Activity was tasked with preparing and exeeuting the APOC 
pre-assessment. The APOC pre-assessment goal is to find the real issues before the 
operational test to be eondueted later. The ehapter eoneludes by outlining the issues that 
the APOC TIWG identified as those that will hinder the transition of Marine aviation IT 
assets to NMCI. 

A. DEVELOPMENTAL TEST PREPARATIONS 

The APOC Pre-Assessment was eondueted at I Marine Expeditionary Eoree’s 
(MEE) Battlefield Simulation Center (BSC) aboard Camp Pendleton, CA, from 24 
January to 4 Eebruary 2005. The DT was engineered and executed by MCOTEA. The 
pre-assessment had two main goals: (1) Confirm that the NTCSS suite of applieations 
would work on the USMC NMCI COI; (2) Establish a working group to identify and 
eoordinate issues eneountered during U. S. Marine Corps aviation’s IT assets transition 
into NMCI network. 

1. Seat Transition 

The eomputers used for the APOC pre-assessment were NMCI CEIN 4ACs, 
ordered through the regular NMCI ordering proeess utilizing the eleetronie marketplaee. 
The enterprise UIC for USMC PM NMCI offiee was used whieh ereated problems with 

11 Development Test (DT) - A development test method attempts to solve problems as they occur. 

Test Integration Working Group (TIWG - The APOC TIWG included stakeholders (see Appendix 
C) to identify and address issues of the Marine Corps Aviation Proof of Concept. 
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the ordering proeess. Ordering seats had always related a single seat with an identified 
user. In this ease, the seats were not mapped to a user, but to the Marine Corps PM 
NMCI office. Upon investigating the status of the seats as the date for the pre-assessment 
grew near, it was determined that the seats had never been created at the NMCI 
warehouse because no user or applications were mapped to the seats. This created 
another dilemma in that the applications being used were not yet tested for the NMCI 
network on the USMC COL 

A waiver was granted by the NMCI DRPM office to allow the seats to be loaded 
with the NTCSS suite of applications for the DT. This was purely administrative since 
the NTCSS suite is a legacy application and approved on the USMC legacy network by 
the USMC aviation software functional area manager (FAM).i3 

2. Training 

MCOTEA provided test training to the identified test subjects and test controllers 
in order to conduct the test effectively. The test training for the subjects consisted of the 
parameters of reporting data for the test. The test controllers also received instruction on 
how to translate test data and document it for the overall test report. This training was to 
ensure the proper results were recorded for analysis. The APOC TIWG also identified 
that the test subjects would require NMCI Deployables training. The Deployables 
training was not restricted to just the test subjects but also included test controllers and 
local CTRs who support local units. The Deployables training was primarily for the test 
subjects who would be deploying their seats from the NMCI network. The Deployables 
training was for knowledge of how the Deployables process works on NMCI. This 
training was also abbreviated to the test controllers to ensure they understood the NMCI 
Deployables process. The Deployables training team from MCSC conducted 
Deployables training for the test subjects. This was the standard training curriculum 
being taught by the Deployables training team throughout the Marine Corps. The Marine 
Corps NMCI Deployables training consists of: 

Functional Area Manager (FAM) - A FAM is responsible for the enterprise of a certain area. In this 
case the USMC aviation FAM is responsible for all aviation software. The FAM approves or disapproves 
changes to USMC aviation software. 
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• Deployables Seat Application 

• Connecting to a tactical network 

• Remote Access Service (RAS) 

• Re-imaging an NMCI seat 

• Returning the seat to an NMCI network 

The documents for the processes and procedures were highlighted for reference to the 
individuals for further learning. 

3. Network Architecture 
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Figure 4. NTCSS Network Architecture 


Figure 4 taken from Pre APOC report dated January 2005. 
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The network architecture for the test used existing NMCI wall plugs located in the 
I MEF BSC. A NTCSS Organizational Maintenance Activity (OMA)!^ server was also 
attached to represent a USMC aviation squadron. 

This OMA server was attached to at the I MEF BSC and linked to the network to 
an NTCSS IMA server located at Camp Pendleton’s airfield. The network represented in 
figure 4 represents a typical NTCSS network for a Marine aviation unit. The issues that 
were initially brought up were the network connections to Navy commands. 

4. Test Criteria 

The test criterion was developed by MCOTEA by referring to NTCSS, NMCI 
Deployables, and EDS documents. The CLINs describing the seat services only refer to a 
seat being supported by NMCI. The NMCI contract did not specify the specifics of what 
kind of support the seat would receive while deployed and while in garrison. The 
following are the relevant test criterions related to the DT. 

Criterion 1 : Solution will permit each flying squadron to maintain a set of 
information resources that support operations in garrison and deployed. These include, 
but are not limited to CSS servers and application servers, shared data storage (servers 
and/or NAS), CSS application report printers. 

Criterion 2: Solution must provide unit IT real-time visibility of status of all seats 
(deployed, not deployed). 

Criterion 3: Solution must provide tools, data, and component condition 
supporting rapid integration into tactical network environment and return into the NMCI 
environment. This may include but is not limited to batch creation of user accounts and 
data, critical applications, workstation accounts, mailboxes. 

Criterion 4: Solution will provide availability of mission critical systems, 
applications, and organizational data through the embarkation phase. 


Organizational Maintenance Activity (OMA) - Aircraft maintenance and equipment used at the 
squadron level. 
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Criterion 5: Solution will provide a validated PUK for any other deployment 
delivered within 96 hours of request. 

Criterion 6: Solution must support operability/interoperability (as required) for all 
mission eritieal applieations (eritieal MOSs, proeess steps). 

Criterion 7: While in garrison, solution will permit the unit to manage CSS 
(NTCSS Programs of Reeord) report printers and information systems, whieh are 
aeeessible by all authorized users at all times. 

Criterion 8: Solution must provide aeeess to these systems [including, but are not 
limited to: CSS servers and application servers, shared data storage (servers and/or NAS), 
and CSS application report printers] from NMCI seats. 

The criterion that MCOTEA set for the APOC pre-assessment covered the both 
the network connectivity issues along with NMCI Deployables support measures. 

B. DEVELOPMENTAL TEST 

The DT was conducted using the criteria created for the APOC pre-assessment, 
which was provided by MCOTEA with input from MCSC Deployables training team, 
EDS Deployables team, and HQMC Aviation. The test criteria was developed from the 
NMCI contract CEINs, which describe the services a particular seat should receive. The 
Deployables Working Group, of which, the MCSC Deployables lead co-chairs, had 
created guidelines to assist the deployable users. While these documents are not 
contractual, they provided a baseline of processes and procedures for the Deployable 
CEINs that were agreed upon by the DWG. The test was conducted by using tasks that a 
Marine AISD tech would be expected to perform in his/her daily duties. 

1. Network Architecture 

The network used for the APOC pre-assessment was setup in the I MEE BSC 
utilizing NMCI wall ports (CEIN 6AB) that had been previously used by the USMC 
Deployables training team to conduct Deployables training. PMW-150 from SPAWAR 
San Diego also setup an OMA NALCOMIS server at the BSC. This OMA server 
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functioned as a squadron OMA server from which actual aircraft maintenance trouble 
tiekets were entered. The OMA server was eonnected to MALS-39 IMA server through 
the NMCI network. This network configuration represented how a Marine aviation unit 
would be conneeted through the NMCI network. 

2. Conduct of Test 

The test was eondueted in reference to MCOTEA’s guidance. Testers were to 
perform their assigned daily tasks and report on the appropriate forms. Interferenee with 
the test was not allowed exeept to troubleshoot network issues. The test eriteria were 
developed by MCOTEA utilizing their test proeedures and polieies. The CLIN 004AC 
deseribes the type of serviee a seat should reeeive while attaehed to the NMCI network. 
The eriteria for these serviees are outlined in the NMCI SLAs. The DT was setup to be 
eondueted in three phases. The first phase represented a Marine unit in garrison. The 
second phase was to demonstrate the ability to deploy the Marine aviation IT assets off of 
the NMCI network. The third and final phase was eondueted to return the Marine 
aviation IT assets back to the NMCI network. 

a. Garrison Phase 

The garrison phase was set up in I MEE’s BSC and conneeted through the 
CLIN 6AB wall ports already installed by NMCI. A NALCOMIS OMA server was set 
up as a Marine aviation garrison NTCSS server. This server was eonnected to the 
MALS-39 IMA server on MCAF Camp Pendleton, whieh aeted as the OMA unit. 

The test area was setup to parallel the tasks performed by Marine aviation 
maintenanee personnel in their daily duties. The tasks ineluded inputting MAFs, 
assigning maintenanee tasks, and requesting replaeement parts through the NTCSS 
system. Aetual MAFs from MALS-39 and MAES-16 were used as the data input for the 
DT. This allowed the traeking of when a MAE was inputted into the NTCSS network to 
when it was resolved. These tasks were then traeed by legaey NTCSS systems to verify 
that the aetions were performed. The tasks performed during the pre-assessment are the 
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essence of a Marine aviation’s maintenance division’s workload. The initial result was 
that the Marine aviation NTCSS applications would function on the NMCI network. 

b. Deployed Phase 

The second phase of the DT was to determine whether Marine NTCSS 
applications would function after the NMCI computer was put through the deployment 
process, which is required to correctly uncouple the Deployable NMCI computer from 
the NMCI network. The NMCI Deployable laptop has a process in order for a Marine 
unit to successfully remove their IT assets from the NMCI environment and gain 
administrator rights to those IT assets. The other point of contention for the NMCI 
Deployables has been the Pack Up Kit. This is the spare laptops and software used to 
temporarily replace a broken NMCI laptop and/or reload the software while the computer 
is deployed. This was done to identify what the PUK actually contained to provide a 
baseline for further PUK requirements. 

The ten NMCI Deployable laptops were identified to NMCI to start the 
deployables process. NMCI then created administrative passwords so that the Unit ITR 
had administrative privileges to the NMIC laptops. Administrative privileges to a 
computer are required so that the Unit ITR can join the Marine aviation unit’s NMCI 
laptops to a Marine tactical network. Due to the testing nature of the deployment, only 
software was requested for the PUK. This was the NMCI gold disk, which would rebuild 
the NMCI computer software to the date the gold disk was created. 

To demonstrate the validity of the reach back capability while detached 
from the NMCI network the ten pre-assessment laptops where taken to MCAS Miramar 
where they where connected to a legacy network. The only reach back capability at the 
time of the DT was through the NMCI dial-up remote access system. This was used to 
demonstrate that a Marine Corps aviation computer could connect back to the NMCI 
network while in a deployed status. NMCI had been working on providing broadband 
remote access capability but did not have it working at the time of the DT. 
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c. Return Phase 

The return phase of NMCI Deployable computers is in essence a reverse 
process of the NMCI Deployables outgoing process. The Unit ITR must contact NMCI 
to initiate the return of the unit’s NMCI deployable laptops to enable the NMCI 
computers the ability to rejoin the NMCI network. This will allow NMCI the appropriate 
amount of time to prepare the network for the returning NMCI computers. For the DT, 
the site preparation was not necessary due to the conduct of the test. The critical issues 
for the returning Marine aviation NMCI computers was to determine what would be the 
effect of re-imaging a Marine aviation NMCI computer with the NMCI gold disk 
software and what network security measures were in place to prevent a network breach. 

C. DEVELOPMENTAL TEST RESULTS 

The tests results provided a quick look at the requirements necessary to transition 
U. S. Marine Corps aviation over to NMCI. The plans and procedures used would 
resemble the current procedures already in place. The main emphasis of the pre¬ 
assessment was to highlight network connectivity and NTCSS applications issues. The 
test results were collected by MCOTEA, which produced an after action report. 

1. Test Criteria Results 

The results for the criteria were positive but also highlighted some deficiencies in 
the NMCI Deployables support functions. Although the primary goal of the DT was to 
determine NTCSS functionality, a number of NMCI Deployables processes were tested. 
The test criterion outlined below will provide a baseline for the OT. 
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Table 1. APOC Test Criteria Results 


Criterion Comments Result 

1. Solution will permit each flying 
squadron to maintain a set of information 
resources that support operations in 
garrison and deployed. These include, but 
are not limited to; CSS servers and 
application servers, shared data storage 
(servers and/or NAS), CSS application 
report printers. 

• Printers worked in garrison and deployed. 

• Shared data storage was successfully 
established in garrison and rapidly 
deployed. 

• Applications performed successfully in 
garrison, remote site, deployed, and upon 
return to NMCI. 

Met 

2. Solution must provide unit IT real-time 
visibility of status of all seats (deployed, 
not deployed). 

• Functionality not available to test. 

Not 

Tested 

3. Solution must provide tools, data and 
component condition supporting rapid 
integration into tactical network 
environment and return into the NMCI 
environment. This may include but is not 
limited to: batch creation of user accounts 
and data, critical applications, workstation 
accounts, mailboxes. 

• Full Functionality not 
available to test. 

• Requirement not formally tested, but 
partially met with 

commercially available 
software. 

Not 

Tested 

4. Solution will provide availability of 
mission critical systems, applications and 
organizational data through the 
embarkation phase. 

• Requirement scoped as 
‘low risk’ by HQMC DCAVN 
rep prior to initiation 
of testing. 

Not 

Tested 

5. Solution will provide a validated 

PUK for any other deployment 
delivered within 96 hours of request. 

• Aviation applications not provided. 

• Gold Disk out of date. 

• PUK received on time. 

Not 

Tested 

6. Solution must support 
operability/interoperability (as required) 
for all mission critical applications (critical 
MOS’s process steps). 

• All tested NTCSS applications were 
interoperable in garrison, remote sites, 
deployed, and upon return to NMCI. 

Met 

7. While in garrison, solution will permit 
the unit to manage CSS (NTCSS Programs 
of Record) report printers and information 
systems, which are accessible by all 
authorized users at all times. 

• Unit ITRs and NTCSS 
administrators could: 

0 Map Printers 

0 Create accounts 

0 Configure apps 

Met 

8. Solution must provide access to these 
systems (including, but not limited to; CSS 
servers and application servers, shared data 
storage (servers and/or NAS), CSS 
application report printers) from NMCI 
seats. 

• Servers, applications servers, printers, and 
data stores were accessible from NMCI 
seats regardless of location. 

Met 
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The results of test eriterion provided a reasonable assuranee that USMC 
aviation ean operate on the NMCI network. There were four major eoncems that would 
need to be addressed before the OT; (1) Standardization of Marine aviation software 
applieations; (2) Solution for NALCOMIS printers to be conneeted to the NMCI 
network; (3) DP-17 van pad eonnection to NMCI; and (4) Cross COI eonneetivity for 
NALCOMIS. 

2. Test Issues 

a. Aviation Applications 

The multiple versions of aviation maintenanee applieations listed in 
DADMS highlighted the requirement for the aviation FAM to establish a list of aviation 
maintenanee applieations to be used by Marine aviation units throughout the enterprise. 
The AISD ehiefs from eaeh of four Marine Aviation Wings along with HQMC AISD 
ehief brought forward every software applieation that eaeh of their respeetive air wings 
used. From this list, the group was tasked to go through the list of aviation applieations 
pertaining to the Marine Corps aviation units and established a baseline of applieations 
that all Marine aviations units would require to operate. 

b. Static IP Addresses for NTCSS Printers 

A NALCOMIS printer was used during the aviation pre-assessment at the 
I MEF BSC. In order for any of the test users to print to the NALCOMIS printer it had to 
be assigned a statie IP by NetCo. This resulted in the issue that the NALCOMIS printer 
driver is imbedded in the NALCOMIS server and thus requiring a statie IP address for 
the NALCOMIS printer to print maintenanee aetion forms (MAFs). The eurrent setup for 
CLIN 6A/B wall ports is to use a dynamie IP address. 

c. DP-1 7 Van Pad Connectivity 

The DP-17 van pad eonneetivity is essential if Marine aviation is to 
migrate to the NMCI network. A large part of a MALS unit eonsists of intereonneeted 
van pads viee an aetual building. In essenee, the DP-17 van pads are meant to deploy for 
a wartime situation but, in reality, they never are moved for that purpose. The issue of 
how to eonneet the DP-17 van pad to NMCI was added to the APOC TWIG list of issues. 
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Figure 5. DP-17 Van pad^® 

d. Cross Community of Interest 

The cross community of interest is one of the key factors which precludes 
the Navy and Marine Corps Intranet from being a true intranet. In reality, the NMCl 
network is two distinct networks that are connected by a few portals. This network setup 
affects communication between Marine Corps and Navy commands that are located on 
the same base. Before NMCI, these commands were on the same base network where 
they could effectively communicate using shared services. Post NMCl removed this base 
network infrastructure thus placing Marine and Navy commands located on the same 
base to revert to other solutions in order to effectively communicate with one another. 
One of the main reasons the Marine Corps resists an all in one intranet with the Navy is 
because the Navy’s IT infrastructure was deemed insecure by the Marine Corps IT 
decision makers. 

Figure 5 taken from Pre APOC report dated January 2005. 
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IV. AVIATION PROOF OF CONCEPT 


This chapter covers the interim period from the DT to the end of the operational 
test (OT) conducted at MCBH, Kaneohe Bay, Hawaii, in November 2005. The OT was 
conducted in order to assess the NMCI functionality of the NTCSS suite of aviation 
maintenance applications on NMCI machines in a garrison and tactical environment. 

This chapter covers how the APOC TIWG worked through the Marine aviation IT issues 
that were identified during the DT. The chapter highlights the critical milestones in 
preparing for the APOC to be conducted at MCAF Kaneohe Bay. The APOC OT is 
covered for the procedures and process taken to ensure the OT could be executed. 

A. PRE-TEST—AVIATION PROOF OF CONCEPT 



Figure 6. MCAF Kaneohe Bay, HI 


MCAF Kaneohe Bay was selected as the test site because it had both Marine 
Corps and Navy aviation units tenanted at the air facility. The Aviation Proof of Concept 
was to include an X-COI test in addition to the ones mandated by the MROC. Hanger 
101 was used as the test center and the tactical environment. The hangar was used for the 
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initial phase in transitioning MAG-24’s aviation computers to NMCI. The hangar office 
spaces were set up for the garrison test while the hanger floor was utilized to set up DP- 
17 van pads for the deployed scenario. 



Figure 7. MCAF Kaneohe Bay Airport Diagram 

Since the aviation pre-assessment in January 2005, the APOC TWIG had been 
working on solving and/or reducing the risk factor associated with the issue brought 
forward from the DT. The risk and mitigation plan followed the likelihood an issue 
would have and the consequences of issue on the program. Figure 8 is the risk and 
mitigation matrix was created for the four main APOC issues after the DT was 
completed. Figure 9 is the risk and mitigation matrix plan for those issues. As seen from 
the graphs, the likelihood and consequences of these issues is high. 
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ConHque nc« 


A. Avation Applications and IJTCSS suite not 
available for Dlt/Q 

B. CLII 5000-Static IPs for tJTCSS Printers not 
in place by DIv/IO 

C. CLRI 27AG - Legacy Server connections not in 
place by Dfi/IO 

D. CLRI 23-X-COI Solution not solved by DM3 


Figure 8. Marine Aviation NMCI Integration Risk Matrix Post APOC DT 
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Figure 9. Marine Aviation NMCI Integration Risk and Mitigation Plan Post APOC DT 

The Marine aviation integration risk matrix listed four main issues; (1) Marine 
aviation applieations; (2) Static IPs for NTCSS printers; (3) CLIN 27 legacy server 
connections; and (4) X-COI connections. The CLIN 27 legacy server issue surfaced after 
the deliberations on whether X-COI would be finalized and whether if connecting the 
DP-17 van pads counted and one or multiple CLIN 27 legacy server connections. 
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The Marine representatives from the APOC TWIG also determined that in order 
for Marine aviation to transition to NMCI at MCAF Kaneohe Bay, and as added elements 
to the Exeeutive Discipline, milestones had to be met. The USMC Aviation Critical 
Milestones are as follows: 

• For all MALs 

- CLIN0027AG approved before DM1 

• For all MAFs & Squadrons before DM2 

- Aviation Applications 

• On Rationalized Fist 

• FADRA Tested 

• For MAFS & Squadrons w/ Cross COI Issues 

- Approved Solution needed before DM1 

- Navy may need to move NAFCOMIS inside B1 



MAG HQ 

MALs (IMA - No 
Cross COI) 

Squadrons (OMA 
- No Cross COI) 

MALs (IMA - Cross 

COI) 

Squadrons (OMA 
- Cross COI) 

MAG Count 

14 

7 to 11 


3 to 7 


DM1 

Can 

Proceed 

Need Design 

Mods* Approved 

Can Proceed 

Need Design Mods* 
Approved; Need Cross 
COI** Resolved 

Can Proceed 

DM2 

Can 

Proceed 

Need 

Applications 

Need 

Applications 

Need Applications 

Need 

Applications 

DM3 

Can 

Proceed 

Can Not Proceed 
until LADRA 
complete 

Can Not Proceed 
until LADRA 
complete 

Can not proceed until 
LADRA complete 

Can Not Proceed 

Seat 

Transition 

Can 

Proceed 

Can Not Proceed 

Can Not Proceed 

Can Not Proceed 

Can Not Proceed 


* Design Mods 

CLIN0027AG availability for DP-17 
6AB Static IP needed 
Business / SLA Review 


** Cross COI USMC C & A recommends all cross-COI seats wait 
until solution in place 

- Navy NALCOMIS needs to move to NAVY NMCI behind the B1 

- SD / HI Regional Cross COI (Will there be a USMC B1 in HI?) 


Figure 10. USMC Aviation ED Guidance Matrix 
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The APOC TIWG created the matrix in Figure 10 to determine the go/no-go 
criteria to proceed with the APOC test. The matrix enhances the execution discipline 
checklist used by NMCl transition teams. 

The APOC TIWG had identified the risks from the DT and spent the time since 
then to fix the discrepancies through technical, management, or contract negotiations. 
MCOTEA was tapped as the lead test agency to conduct the APOC. They recommended 
that a test user base be set for forty computers to be transitioned before the APOC test 
thirty days in order to provide stability before the OT was conducted. The next critical 
step was to ensure that the Marine aviation maintenance applications were approved in 
DADMS and LADRA tested at MCAF Kaneohe Bay in order for the computer build out 
to proceed. 

1. Network Architecture 

The network architecture was established by the EDS’s subcontractor NetCo in 
accordance to meet SEAs for the NMCI contract. One of the important tasks in the 
process is for NetCo to complete build out (BIOS) of a site in order to support the 
network. The bandwidth requirement must not exceed 80% to allow a 20% surge 
capability. This is a critical factor if the network architecture is not capable of providing 
the necessary bandwidth. If the site undergoing transition does not meet network 
capability then NMCl is responsible for upgrading the network infrastructure. The 
network that NMCl contracted for included the infrastructure of the Marine Corps. 

MCAE Kaneohe Bay had an insufficient network, which required upgraded infrastructure 
to meet the SEA requirements. In order to meet the APOC timeline, emphasis had to be 
placed on the upgrade of the network infrastructure. 

The other issue with the network architecture is related to the X-COI. Eigure 11 
shows an NTCSS network before transition into NMCl. Eigure 12 outlays the NTCSS 
network connections after the transition to NMCl. The crutch of the issue involving the 
base network is to allow certain portals to be connected in order to transfer data. In the 
case of MCAE Kaneohe Bay, the portal of RCP 514 was highlighted as one that would 
require the X-COl solution. 
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Navy NMCI seats that has a client that 
talks to the Navy Legacy NALCOMIS 
IMA Server via port 4050 
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Figure 11. NTCSS Network Configuration Pre NMCI Transitioni^ 


Figure 11 is from an APOC Assessment Brief 
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Navy NMCI seats that has a client that 
talks to the Navy Legacy NALCOMIS 
IMA Server via port 4050 


AFTER NMCI Transition 



Figure 12. NTCSS Network Configuration Post NMCI Transition!^ 


Figures 11 and 12 outline the main features of the NTCSS network before and 
after transition to the NMCI network. After the transfer to NMCI, all portals that were 
previously used to transmit between a Marine and Navy unit’s NTCSS applications were 
no longer open. The Marine Corps and Navy DAAs do not have an agreement to allow 
X-COI connections. There are temporary allowances but no final solution has been met. 


Figure 12 is from an APOC Assessment Brief 
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Figure 13. NTCSS Network Configuration Post NMCI Transition Issues^^ 


Figure 13 highlights the issue of the RCP 514 protocol after Marine aviation 
transition into NMCI. In order for Navy’s aviation servers to connect to MALS-24 
NTCSS servers, they must go out of the Navy’s NMCI COl and into the Marine Corps’ 
NMCI COl to reach the NTCSS servers. This is the issue of why the Marine Corps C4 
DAA was reluctant to allow any cross connections between the Marine Corps and the 
Navy’s NMCI networks. With the architecture network at MCAF Kaneohe Bay being 
upgraded to meet SLAs, the APOC TIWG worked at the X-COl issue to ensure it would 
not stop Marine aviation from transitioning into NMCI. 


Figure 13 is from an APOC Assessment Brief 
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2. Aviation Software Applications 

The results from the pre-assessment eonducted in January 2005 at Camp 
Pendleton, The Marine aviation FAM established the requirement of standardizing all 
Marine aviation maintenanee applications. The FAM for Marine Corps aviation 
maintenance applications tasked the ALD Chiefs from each of the four Marine Air Wings 
to prioritize their lists of applications and to consolidate the applications into one list that 
could be a standardized for all Marine aviation units. The first step was to determine 
what each MAW was using at each of their respective air bases. The initial list contained 
over one hundred applications. A large part of this list contained the same application 
with different versions. SPAWAR PMW-150 as the custodian of all Naval and Marine 
aviation applications was also instrumental in collaborating with the Marine aviation 
FAM to consolidate the Marine aviation maintenance software list. PMW-150 updates 
and test upgrades to the NTCSS suite as necessary but does not set precedence on which 
version an air wing utilizes. PMW-150 does not conduct NTCSS application upgrades 
compatibility on NMCI networks. As noted before, the Navy Air Forces have their 
NTCSS servers on the B2 network, which is not the NMCI network proper. The different 
applications could be equated to having Windows 2000 and one unit upgrades to 
Windows XP. The unit is compliant but has functionality is limited to Win2000. This 
resulted in the aviation template being created in Integrated Solutions Framework Tools 
and would be used as the template for all of the Marine aviation seats. The USMC 
aviation maintenance standardized software applications are listed in the USMC aviation 
template is in appendix E. 

The creation of a standardized template is attributed to the leadership of the 
HQMC’s AIS chief and the Marine Corps four MAWs ALD chiefs who took it upon 
themselves to ensure that all Marine aviation commands would have the same aviation 
maintenance applications enterprise wide. The group was able to push this issue through 
in a relatively short time period because they were the leadership for Marine aviation 
maintenance technology. 
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3. 


Seat Transition 


The transitioning of a site is the first step toward the overall goal of seat 
transition. All Marine Corps installations and units must go through the Exeeution 
Discipline process in order to identify issues to transition efficiently. The pressure to get 
all seats in the Marine Corps transitioned over to NMCI had created the need to get all 
Marine Corps aviation units prepared to transition as soon as they are ready in accordance 
with Execution Discipline. The desired process of conducting the OT and then 
implementing those results into further seat transitions had been negated due to the long 
periods of non-transition periods. The DRPM has directed that the Marine Corps try to 
complete transition by the end of calendar year 2006. The seat focus for the first 
transitions at MCB Hawaii concentrated on the APOC test computers. 

The APOC TIWG, Base Ops MCB Hawaii, CTRs at Hawaii, and EDS met 
weekly to identify any problems in preparing MAG-24 for transition into NMCI. The 
APOC test was to be the frontrunner for the rest of the MAG-24 and Marine Corps 
aviation to transition to NMCI. Although the test was supposed to run for approximately 
one month, the rest of MAG-24 units were to continue to transition seats at the rate of 
125 per week. The APOC TIWG had worked to ensure that the standardization of seats, 
software, and network connectivity were the same across Marine Corps aviation sites to 
allow CTRs to go by a set of business rules to simplify the ordering process. The first 
component that the APOC TIWG agreed upon was the hardware configuration for 
Marine aviation. This was actually a Marine aviation decision due to funding and 
deployability of the seats. The only alternative hardware available at that time was the 
Dolch ruggedized laptop, which was not given consideration by the APOC TIWG due to 
its high price and unreliability. Since virtually all Marine Corps aviation units deploy, 
the decision to make all of the hardware to be the same deployable CEIN was a logical 
decision. Since all machines were to be deployable CEINs, the issue was to determine 
what would be the best hardware CEIN for the best price. It was decided that the CEIN 
4AC was suitable for Marine Corps deployed units in that it provided the basic hardware 
and software to support a deployed Marine Corps unit at the best cost. The other concern 
was to ensure that the Marine aviation seats were accurately ordered through the 
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enterprise management program. This would inelude the proper user, software 
applieations, unit, billing, and delivery. The NMCI enterprise tool to the eentral data 
repository is outlined in the following to figures. 



Figure 14. NET to CDR Overall Proeess Flow^o 


The transition of the APOC eomputers was aeeomplished in aeeordanee with ED. 
The first forty seats to be transitioned for MAG-24 were identified as the APOC user’s 
seats in order to fulfill the 30-day stabilization test requirement. This order was given a 
higher priority by NMCI in order to meet the 30-day stabilization window. 

The Marine aviation seat transition risk and mitigation matrix is very similar to 
the overall Marine aviation seat transition issues. The only notable differenee is that the 
CEIN 27 legaey server issue was replaeed with the DP-17 van pad issue. It was reasoned 
that if the DP-17 van pads eould not be eonneeted through either legaey or NMCI then 
the risk would be too great sinee the majority of MAES eomputers were loeated in DP-17 
van pads. 

Figure 14 is from PM USMC NMCI brief of Ordering NMCI Products from January 2005. 
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Figure 15. Marine Aviation Seat Transition Risk Matrix Post APOC DT^i 


4. DP-17 Van Pad Operations 

The DT condueted at Camp Pendleton presented the problem of how the DP-17 
van pads would be conneeted to the NMCl network. During the time following the DT, 
EDS network engineers, SPAWAR PMW-150 SMEs, and Marine Corps ALD SMEs 
taekled the issue of how to support the DP-17 van pads used by Marine aviation. The 
first issue was to determine what and whose responsibility for eonneeting and supporting 
the DP-17 van pads to the NMCI network would be. It was agreed upon that all of the 
wiring inside the DP-17 belong to the Marine Corps. NMCI would provide NMCI 
eomputers and printers according to the NMCI contract. This issue was argumentative 
due to determining what constituted a building. NMCI requirements where only to 
provide computers to structured buildings vice the temporary DP-17 van pad structures. 
The issue was concluded in that the DP-17 van pads where structures because they were 
in place before the NMCI contract and had computer assets associated with them. 
However, since they were mobile the government owned the wiring inside the DP-17 van 
pad. 

A meeting was held with EDS engineers. Marine Cops ALD SMEs, PMW-150 
SMEs, and the APOC TWIG to determine problem of connecting the DP-17 van pads 
and to propose solution/s to solve the issue. After Marine Corps ALD explained the 
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Figure 15 is from the APOC Risk Analysis Brief 
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process and procedures of how NALCOMIS works and where the DP-17 van pads fit in 
the scheme, a resolution was created that would use a pedestal for NMCI network 
connectivity to the DP-17 van pads. The diagram below was created and used for the 
DP-17 van pad agreement. The DP-17 van pad agreement is outlined in Appendix F. 





= Bldg/Van Pad 


Figure 16. NMCI / USMC DP-17 Van pad Agreement Schematic^^ 


The DP-17 van pad issue was the easiest problem to resolve once the problem was 
identified to all parties. Figure 12 was the schematic drawn out during the collaboration 
meeting to solve the DP-17 van pad issue. 

Figure 16 is from the NMCI/EDS Van Pad solution document. 
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5. 


NTCSS Printers 


In accessing the requirements for a sueeessful transition of Marine aviation assets 
over to NMCI, it was determined that—in order for NTCSS printers to funetion on the 
NMCI network—^NTCSS printers required a static IP address and a eonneetion to the 
NTCSS server. The NTCSS server hosts the printer queue for NTCSS print jobs. This 
was one of the discovery items found during the aviation pre- assessment. In researching 
alternatives, it was determined that NTCSS Legaey OMA print jobs would not elear from 
the print spool on an NMCI printer. LOMA substantiates the largest part of the Marine 
aviation applieations. All of the other Marine aviation applieations were eapable of 
printing to NMCI printers. During the Oetober 2005 Seienee, Teehnology, Engineering, 
and Arehiteeture Group eonference, it was diseovered that there was a fix for elearing the 
LOMA print jobs from the NMCI printer queues. The issue then beeame to determine 
whether all NTCSS applieations would be eapable of utilizing NMCI printers. 

The NTCSS printers still required a solution in order for the NTCSS printers to 
have a statie IP and eonneetivity with the NTCSS print server for the APOC. MCSC and 
EDS had been in negotiations about what serviees were being used by the NTCSS 
printers so that the eorreet CLIN eould be plaeed in eMp. EDS suggested in Eebruary 
2005 that a CLIN 5000 be ereated so that EDS eould engineer and implement a solution 
for a one-time priee. MCSC analyzed the proposal and other alternatives and then 
ereated a request in the NMCI Request Aetion Program. A CLIN 5000 was ereated for a 
proposal on the establishment of static IP addresses and eonneetivity between wall ports 
and NTCSS printers. 

Another factor that confused the NTCSS printer issue was that the Navy Air 
Eorees purehased CLIN 6AB wall port eonneetions for their NTCSS printers. The Navy 
Air Eorees even purchased NMCI printers in plaee of eonneeting their NTCSS printers in 
garrison. The issue of whether NMCI was responsible for eonneeting the legacy NTCSS 
printers to the NMCI network was eontroversial in several aspeets. Marine aviation’s 
viewpoint was that the printers were eonneeted to the MCEN before NMCI and were still 
utilized heavily beeause the NMCI printers were not eompatible with the NTCSS print 
server. NMCI’s view was that the added NTCSS printers added a burden of network 
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connections and bandwidth to the NMCI network. From these conferences and 
discussions, a new set of requirements for NTCSS printer utilization was formed. 

Requirement - Determine the NTCSS printing requirements for Marine aviation 
and logistics units. 

Speculation - The current NMCI printing solution does not support the printing 
requirements of Marine aviation squadrons and aviation logistics squadrons. 

From these rudimentary requirements and observations, three courses of actions 
were formed to determine the best method to move the project forward. 

Option 1 - Create a new CLIN that uses existing connections where NTCSS 
printers are already in place. This CLIN would represent a fair price for providing a 
static IP address and a low bandwidth connection between the NTCSS print server and 
the NTCSS printer. No other NMCI services are required. 

Option 2 - Modify the existing CLIN 6AK to enable the low-bandwidth 
connection to a wall plug. This would also include a CLIN 6AH for a static IP address. 

Option 3 - Purchase the CLIN 6AB for NTCSS printers. 

NMCI was also creating a new CLIN, CLIN 6AR, which dealt with Program of 
Record devices. The CLIN 6AR is essentially a CLIN 6AB with a connection fee. The 
procuring contract officer had approved the creation of the new CLIN 6AR. However, it 
would take it a few months to get through all of the approvals before it was included in 
the contract modifications. 

The risk of moving forward with the APOC test in spite of a NTCSS printer 
solution was high on the factor of not coming to a solution but would not keep the 
schedule from moving forward as the NTCSS printers could still be connected through 
the legacy network. 

6. Cross Community of Interest (X-COI) 

The X-COI issue became visible when the Naval Air Forces began transitioning 
their NTCCS system over to NMCI where Marine aviation units and Navy Air Force 
units shared the same MALS or Navy Aircraft Intermittent Maintenance Department. In 
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order to facilitate the Naval Air Force’s transition at aviation-shared sites, an interim 
solution was put in place that allowed inbound RCP traffic from the USN COI into the 
USMC COI. This solution was designed to be temporary in nature due to the 
vulnerabilities associated with this service. This solution was still in place when the 
APOC took place. 

In order for Marine aviation to transition at every site NMCI would have to 
engineer, implement and manage an X-COI connection between the USMC and USN 
VPNs at the shared site transport boundaries where one was required. The connection 
must ensure that only required ports and protocols are allowed to specific IPs. 

The requirements set by SPAWAR System Center Norfolk, which would allow 
the NTCCS print servers to function on the NMCI network to the NTCSS printers, are 
listed below: 

A. Each NTCSS I-LEVEL implementation requires the ability to print 
using EPR TCP 515 from either the HP (HPUX 10/20) or Sun (Solaris 
7/8) suite. 

B. Maintain the OMA-IMA Interface, a bi-directional communication 
path, for aviation squadrons to order parts and perform status queries 
from their supporting AIMD or MAES NALCOMIS server. The 
OMA-IMA interface utilizes different TCP ports to perform data 
transfers depending on the hardware/software configuration for a 
particular squadron and its supporting I-EEVEE host. 

a. The three supported OMA-IMA configurations are: 

1. EOMA to EIMA Configuration: TCP 23 (telnet) 

2. EOMA to OIMA Configuration: TCP 514 (RCP - remote 
copy) 

3. OOMA to OIMA Configuration: TCP 4050, 4100 (Sybase to 
Sybase) OOMA Client to OIMA: TCP 9132, 9142, and 4050 

C. Provide communication ports for OOMA clients to access OIMA 
when both the squadrons and I-EEVEE are optimized. TCP ports 
9132, 9142 (subset of the NTCSS desktop) and 4050 (Sybase 
database) allow the OOMA client to authenticate to one of the two 
NTCSS servers and login to the NALC server to perform status 
queries. This connectivity will only be allowed via specific designated 
hosts. 
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NTCSS OMA - IMA Interface Configurations 
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Figure 17. OMA - IMA Interface Configurations^s 

The majority of the Marine aviation units requiring an X-COI solution were 
located on either a Naval Air Station or a Joint Reserve Base. The sites identified 
requiring an X-COI are listed below. 

• MCAF Kaneohe Bay, HI 

• MCAS Beaufort, SC 

• JRB/NAS Ft. Worth, TX 

• NAS Norfolk, VA 

• NAS Atlanta, GA 

• JRB/NAS New Orleans, LA 

• NAS Willow Grove, PA 

• NAF Washington/Andrews AFB, MD 

Figure 17 is from NTCSS/NMCI Communication Infrastructure Requirements vl.5. 
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The risk factor of proceeding with the APOC was considered low enough despite 
the fact that there was still not an X-COI solution. Since there was a temporary solution 
in place, it was agreed upon by the APOC TIWG that the APOC should move forward. 

B. TEST—AVIATION PROOF OF CONCEPT 

The APOC TWIG had tried to resolve the critical milestones to meet the project 
plan for the APOC. The APOC TIWG laid out the completion dates for the critical 
milestones in order for the APOC to be conducted. The list of the critical milestone dates 
are listed below: 

• Marine Aviation Maintenance Applications - 5/16/05 all applications on 
RAT List 

• High Level Design (DP-17 Van Pad) - 5/13/05 

• Formal Staffing Contracts between EDS/USMC - 5/13/05 

• BIOS - Build out of network architecture - 5/30/05 

• LADRA Testing - 6/21/05 

• NTCSS printer solution in place by the end of August 

• X-COI solution in place by the end of August 

The Marine aviation maintenance software applications and LADRA testing were both 
completed in a timely manner. The DP-17 van pad solution was outlined to be installed 
during MAG-24’s NMCI transition. The X-COI solution, NTCSS printer solution, and 
formal document signing between NMCI and the government were the critical issues that 
had not been completed before the APOC was scheduled to start. 

The initial concept for the APOC was to perform a full-scale realistic test that 
would encompass an entire Marine Corps aviation unit. The OT was to include an actual 
unit departure from the confines of a base infrastructure to accurately test the deployable 
capability of the NMCI Deployables processes. However, due to the Iraqi war, there was 
not enough resources to do the tactical deployment as envisioned. Following the delivery 
of the forty NMCI test computers it vital to ensure that the APOC represented a 
semblance of Marine aviation. 
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1 . 


Test Criteria 


The test eriteria used for the APOC was the same used for the APOC pre¬ 
assessment. The test criterions were reviewed again to ensure they were still valid. 


2. Schedule of Events 

The sehedule of the APOC test was categorized into the phases listed below: 


• NMCI Deployables training 

• MCOTEA brief to APOC participates 

• Pilot Test 

• Garrison Phase 

• Composite Phase 

• Deployment (external) Phase 

• Reintegration Phase 

• Breakdown 


25-28 Oct 
31 Oct 

31 Oct - 2 Nov 
3-4 Nov 
7-9 Nov 
14-23 Nov 
24-30 Nov 
1-2 Dec 


The training and garrison phase would resemble how the NMCI Deployables 
process works. The composite, deployment, and reintegration phases also constituted 
what actually occurs in a Marine Corps deployment cycle. The processes were kept true 
to their concept except they were placed on a compressed schedule. 

3. Training 

The APOC pre-assessment training was two-fold. Deployables training for the 
Unit IT Reps, testers, and test controllers was conducted to educate them on the NMCI 
Deployables process. Test user training was conducted with all users to ensure that data 
would be properly captured correctly. The final breakdown of APOC testers and data 
collectors were as follows: 

• (30) testers from MATS 24 

- 27 NMCI machines 

• (17) testers from HMH 363 
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- 7 NMCI machines 

- 7 Users throughout the APOC (All Four Phases) 

- 10 Additional Users will augment the HMH “Det” during the Deployed 
Phase and will eonduct routine maintenanee transaetions on an actual 
CH-53D helicopter. 

• (15) Data collectors 

- MALS (8) 

- HMH-363 (5) 

- MAG HQ (2) 


4. Network Architecture 



Figure 18. NMCI Network Configuration for MCAF Kaneohe Bay^^ 

The test maehines were NMCI maehines, (CLIN 4AC), that had been transitioned 
for HMH-363s and MALS 24. The network drops for the garrison phase were the 
individual users’ aetual workstations. The tactieal network architeeture used by the test 
machines was designed by MALS 24 AISD, MCOTEA, NMCI, and NetCo personnel to 
establish a link between the OMA servers loeated at the Deployed test site and the IMA 
server located at MALS-24. 

Figure 18 is from USMC APOC Awareness Brief May 2005. 
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Figure 18 outlines the NMCI network connections for the Marine Corps and Navy 
COIs on MCAF Kaneohe Bay. Appendix H contains all of the build out diagrams for 
MCAF Kaneohe Bay. The networking diagrams outline where MAG-24’s NMCI 
computers and printers are to be located. This was part of the Execution Discipline 
process to which NMCI validates what government IT asset is actually where it is or is 
not suppose to be. The network architecture for NMCI as a whole had not encountered 
any major problems until Marine aviation was scheduled to transition. This is due mainly 
to the large number of IT assets that Marine aviation possesses and to the age of the 
networks where Marine aviation units are located. 



ConMqusncs 


A. .A-Gation .Applications and XTCSS 
suite not available for DM2 

B. CLIN 5000 -Static IP's for NTCSS 
Printers not in p lace bv DM3 

C. CLIN 27AG-Legacy Ser^-er 
connections not in place by DM3 

D. CLIN 29 - X-COI Solution not solved 
bv DM3 


Figure 19. Marine Aviation NMCI Integration Risk and Mitigation Matrix Pre APOC^^ 

The NMCI transition team was able to complete the transition of the forty test 
machines in the prescribed time to allow for the thirty-day stabilization period. The 
Marine aviation applications had been standardized and placed in DADMS where a 
template was created for MCAF Kaneohe Bay. The other risks of NTCSS printers, DP- 
17 van pads, and CLIN 27 legacy server connections were reduced to an acceptable level 
by either technical or temporary contract solutions. It was concluded by the APOC 
TIWG that the OT could commence. 


Figure 19 taken from APOC Risk and Mitigation Brief. 
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5. 


Test—Garrison Phase 


The office spaces in hanger 101 at MCAF Kaneohe Bay were transitioned by 
NMCl following the ED process just as they would be for a normal transition. The forty 
APOC test computers were also identified and transitioned first. Note; the testing 
computers were not assigned to hanger 101 which was home to HMH-362 who were 
deployed. The APOC testers predominantly came from MALS-24 and HMH-363. 
Figure 20 displays the APOC test computers and location. 
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The garrison phase of the APOC OT followed the users in their day-to-day 
routine jobs functions. Each user completed a task assigned by MCOTEA to determine 
whether the Marine aviation maintenance applications functioned properly on the NMCl 
network. Trouble points were evaluated only to ensure the OT could continue. The test 
users filled out data sheets each day relating to their assigned tasks. Test controllers 
collected the data each day to be evaluated after the conclusion of the APOC OT. This 
procedure would be subscribed to in each phase. 

Following the garrison phase, the test users were brought together at the deployed 
test site to determine that the NMCl network would support the scenario. This was to 
Figure 20 taken from APOC Report November 2006. 
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facilitate the question for the Deployables on whether NMCI eould support a composite 
unit such as an element of a Marine Expeditionary Unit. The network eonneetivity 
proved to be a sueeess and the APOC OT prepared for the deployed phase of the test. 

6. Test—Deployed Phase 

The taetical network was set up using DP-17 van pads in hanger 101 to simulate a 
tactical environment. The taetieal seenario was deemed a simulation since the DP-17 van 
pads were using base utilities. This still provided separation from other aetivities, but 
allowed locality for logistical ease. 



Figure 21. DP-17 Van Pads APOC Deployed Test Site^^ 


Figure 21 photograph taken by Major G. R. Flightower. 
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Figure 22. Hangar 101 Deployed Site Diagram^* 

The deployed test site was established as an actual MATS unit would be except 
for its size. It contained all of the necessary IT requirements to function as a forward 
deployed MALS/squadron maintenance department. The number of APOC test users for 
the deployed phase was thirty-seven—thirty from MALS-24 and seven from HMH-363. 
Twenty-seven NMCI computers were relocated to Hangar 101 for a total of thirty-four 
APOC test computers. 

The APOC test users were once again assigned tasks by MCOTEA just as before 
in the garrison phase. The key element in the deployed phase was to determine whether 
Marine aviation maintenance application would function properly after the NMCI 
computers had completed the NMCI Deployables process. The OT for the deployed 
phase was conducted and preparations for the reintegration of Marine aviation IT assets 
back to the NMCI network were initiated. Normally this process has a minimum 
notification timeframe to allow NMCI the time to prepare for a units return to NMCI. 

The processed was compressed due to time constraints and resources. 


Figure 22 taken from APOC Report November 2006. 
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7. Test—Return to Garrison Phase 

The return to garrison phase followed the NMCI Deployables business rules for 
returning NMCI Deployable computers back to the NMCI network. The key aspect for 
this phase of the test was to determine the effect of reconnecting several different 
configurations of Marine Corps aviation NMCI computers. One would be a Marine 
aviation NMCI computer in which the configuration had not been changed since it was 
deployed; one of which unauthorized NMCI software programs had been added; and one 
where the computer had been re-imaged with the NMCI re-imaging software. The rest of 
the return to garrison phase was to test the logistic side of the NMCI Deployables. 

C. POST-TEST—AVIATION PROOF OF CONCEPT 

The post-test results from the APOC OT were collected and analyzed by 
MCOTEA who would produce a formal report of the test. The initial results were that 
Marine aviation could operate on the NMCI network without service interruption. 

1. Network Architecture 

The NMCI network functioned properly except during a time period when APOC 
test users were following the steps to properly detach their NMCI computers from the 
NMCI network. It was initially thought to be the NMCI Deployable application failed 
but turned out to be a network connectivity issue at MCB Hawaii. 

2. Seat Transition 

The NMCI aviation template created by HQMC AVN provided the basis for all 
USMC aviation maintenance seats. This template included the forty-two Marine aviation 
maintenance applications, which include the NTCSS suite that is necessary for managing 
aircraft maintenance actions. The garrison phase of the OT was conducted without any 
major issues in regards to the aviation maintenance applications. After the deployment 
and return phase of the OT, it was discovered that out of the forty test seats transitioned 
for the OT, all had one or more of the Marine aviation maintenance applications missing. 
After further discussion, it was not conclusive if the missing aviation maintenance 


applications were ever loaded on the APOC test computers from the NMCI warehouse. 
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The NMCI ED process has had multiple challenges during the transition period. 
Accountability of government IT assets was the biggest issue to resolve when 
transitioning a unit/base. The NMCI ED process sought to validate what was at the site; 
determine what the unit has ordered; and then correctly enter that all in the database so 
that the NMCI warehouse could configure the computers for each user correctly. Eigure 
23 outlines the NMCI process of the CTRs order to delivery process. 
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Eigure 23 - NMCI Order to Delivery Elow^^ 

3. Marine Corps Aviation Issues 
a. Aviation Applications 

The aviation template created in DADMS proved to be a proven process in 
moving the transition of Marine aviation into NMCI. The template allowed Contracting 
Technical Representatives to streamline their NMCI orders in selecting the Marine 
aviation template vice making a selection of different applications. 

Figure 23 taken from PM USMC NMCI brief of Ordering NMCI Products from January 2005 
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b. Static IPs for NTCSS Printers 

The use of NTCSS printers in a garrison environment has been neeessary 
due to the incapability of the NTCSS print server with the NMCI printer. The temporary 
solution of allowing NTCSS printers to connect to the NMCI network without levying a 
CLIN against them since there was not a decisive hindrance to the APOC OT. 

c. DP-1 7 Van Pad Connectivity 

The DP-17 Van Pad connectivity diagram that was agreed upon by 
HQMC AVN, EDS, and PMW-I50 would be used for the tactical portion of the test. 
While the DP-17 network connectivity diagram is being used throughout the Marine 
Corps, there was still no official documentation during test. 

d. X-COI 

The X-COI RAP is still under review by EDS. Awarding and engineering 
the X-COI solution would require considerable time. Therefore, it was not included as 
part of the APOC test. The temporary connection of specified portals would have to be 
agreed upon at each base. 
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V. MARINE AVIATION NTCSS SERVER TRANSITION 


Chapter V covers the Marine Corps Aviation NTCSS server transition from the 
Marine Corps Enterprise Network to the NMCI network. It describes the CLIN 27 server 
connections in relation to the NMCI contract. The CLIN 27 AG Legacy Server 
connection is explained as it pertains to the NTCSS server connections, HQMC C4, and 
the NMCI contract. Chapter V also describes the CLIN 27 AG issues and solutions 
related to the NTCSS server transition. 

A. CLIN 27 

The CLIN 27 server connections were created to account for all of the NIPRNET 
and SIPRNET server connections for the Navy and the Marine Corps servers on the 
NMCI network. The servers that had a program of record and placed in the legacy 
category were predominately planned to connect with the CLIN 27 AG legacy 
application server connection. The CLIN 27 AG server connections were managed by 
HQMC C4 and would be given to the Marine Corps IT systems according to priority. 
HQMC C4 established the process in MARADMIN 308-05 Message DTG 130027Z JUL 
05 policy for NMCI CLIN 0127AG selection and approval. NMCI also had requirements 
for selected server/applications to be placed on the NMCI network. Each application 
hosted on the server must comply with the following: 

- Must have a current lATO/ATO issued by MCNOSC 

- Must be identified in DON Application and Database Management System 
(DADMS) as Lunctional Area Manager (LAM) "Approved" 

(LAM "Allowed with Restrictions (AWR)" applications will not be considered)) 

- Must employ the most current version of the client application operating on 
NMCI 

- Must employ a client application that has been certified and deployed on the 
NMCI environment 

Since NTCSS was a program of record, HQMC Aviation ALD already had the required 
paperwork in place that would place the NTCSS servers in a high priority for CLIN 27 
AG connections. 
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1 . 


CLIN 27 AG 


The original NMC contract included server connectivity for 2100 legacy 
applications. The contract language was ambiguous and inconsistent with the processes 
that NMCI used to manage services. PM-NMCI and EDS agreed to an alternative 
arrangement, which was detailed in Naval Message “PEO IT WASHINGTON DC 
22I9I3Z APR 05.” 

- This message set the maximum number of 0I27AG server connections at 
5,000, which was broken out to provide 1,429 server connections for USMC 
and 3,571 for the USN. This agreement provided some criteria for CEIN 
0127AG usage (see business rules) and clarified that the CEIN 0127AG could 
not be used for DMZ services. 

The CLIN 27 AG legacy application server connection was selected as the 
primary contract vehicle to connect the Marine aviation NTCSS servers to the NMCI 
network. 

The main reason is that the CLIN 27 AG legacy application server connection had 
a zero dollar cost associated with it. It can be connected to low, medium, or high 
bandwidth (10MB, 100MB, 1GB) on the NMCI network depending on the base/site 
infrastructure. 

The Marine Corps as a whole received around 1429 of the 5000 available CLIN 27 AG 
connections allowed for the NMCI network. 

The HQMC C4 and the Marine Corps PM NMCI office followed the criteria set 
by the PEO-NMCI office for both the Navy and Marine Corps. Priority is as follows: 

1. DON/DoD mandated 

2. Programs of Record (POR) 

3. Mission Critical (MC) 

4. Mission Essential (ME) 

5. Joint (USAAJSAE/JTF/DHS) 

6. Others (Command/Unit) 

Marine aviation NTCSS servers had three of the top four of the CLIN 27 AG criteria. 

The NTCSS program was run as a program through PMW-I50 and was a program of 
record. It was mission essential to the operational readiness of all Navy and Marine 
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Corps aviation units. The mission critical status was confusing since it was critical to the 
Marine Corps aviation units but NMCI used the term for IT systems that must never be 
inoperative. While NTCSS could not be down for any prolonged period, it was not 
labeled as mission critical. The three categories that the NTCSS servers did qualify for 
were enough to allow them to be granted CLIN 27 AG legacy application server 
connections. 

2. CLIN 27 AG Orders 

Marine aviation had the necessary priorities in order to be allotted the necessary 
CLIN 27 AG connections to connect all of the NTCSS servers operated by Marine 
aviation flying and maintenance squadrons. Each Marine flying squadron has two 
NTCSS servers and each MALS has four NTCSS servers. The number of total servers 
after the APOC came to 249. Each CTR at each base/site was required to provide 
documentation of the DON/DoD mandate when placing your order in NET. After the 
CEIN 27 AG orders were placed in NET, the CEIN 27 AG transition would begin with 
decision meeting (DM1). 

The CEIN 27 AG transition followed the CEIN 27 transition process with 
decision meetings one, two, and three. These DMs were established to ensure that NMCI 
and the Navy and Marine Corps users had met the requirements for the designated servers 
to be transition in to NMCI. 

B. CLIN 27 TRANSITION FOR NTCSS SERVERS 

A CLIN 27 working group was formed to facilitate the transition of Navy and 
Marine Corps servers into the NMCI network. This process followed a plan mimicking 
the Marine Corps NMCI Program Office’s Execution Discipline procedure for 
transitioning a base/site to NMCI. After a CTR submitted an order for one of the CLIN 
27 server connections, decision meetings with all of the stakeholders was held to ensure 
all of the necessary requirements were met. The CLIN 27 AG legacy server connections 
were included in the overall CLIN 27 server transition process. 
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1. Base/Site Preparations 

The first requirement for transitioning Marine aviation NTCSS servers over to the 
NMCI network was for all of the Marine aviation computers at the base/site to be 
transitioned over to NMCI. The other crucial requirement was for PMW-150 to ensure 
that the NTCSS server had the required updates and patches to transition into NMCI. 

The base/site network infrastructure was not an issue since the base/site network had 
already undergone capacity testing during the computer transition. 

2. CLIN 27 AG NTCSS Transition Schedule 

The NTCSS server did not have a concrete schedule. This was due to some sites 
still undergoing seat transition while others were completely transitioned. The schedule 
for the CLIN 27 AG transition was included in the overall CLIN 27 transition process. In 
such, the schedule of transition was based on which Navy or Marine Corps base/site had 
met the CLIN 27 execution discipline process and available NMCI resources. 

3. CLIN 27 AG NTCSS Transition Issues 

There were no technical issues that halted or delayed the NTCSS transition. The 
only transition issues were administrative. 

C. CLIN 27 AG NTCSS TRANSITION RESULTS 

The CLIN 27 AG transition was a success to get all of the Marine Corps aviation 
NTCSS servers into NMCI. The plans and procedures used by the CLIN 27 working 
group outlined the issues and resolved them in a timely manner to ensure the successful 
transition. 
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VI. SUMMARY AND CONCLUSIONS 


Chapter VI summarizes the Marine Corps Aviation Proof of Concept and the 
transition of Marine aviation IT assets into NMCI. It highlights the four issues 
discovered during the APOC DT and their current status. The NMCI contract will be re¬ 
competed in 2010 under the project called the Next Generation Enterprise Network. The 
chapter concludes with examining future research in supporting the Marine aviation 
NTCSS network environment. 

A. SUMMARY AND CONCLUSION OF THE APOC 

The NMCI network became a reality after the contract was signed on 6 October 
2000. Many Navy and Marine Corps communities resisted the change while some 
welcomed it. The NMCI contract was written in record time despite the millions of 
dollars being committed by the DON. The five-year history of the DON conversion over 
to NMCI has encountered almost every possible obstacle and issue imaginable. Despite 
these valuable lessons learned, the MCSC NMCI PM office faced many difficulties to 
effectively transitioning Marine Corps IT assets over to NMCI. 

The standards and configuration management that was used to transition USMC 
aviation over to NMCI helped to baseline all of the hardware, software, and other 
periphery equipment used by all of Marine Corps aviation enterprise wide. The effort to 
get all units on the same level with all other units enhanced the compatibility across all 
USMC units. 

NMCI did level the playing field between the units who had sufficient IT assets 
and those who did not. The general accountability for IT assets had not been held to the 
accountability standards that some other IT systems had. The bulk of Marine aviation’s 
computers were NTCSS computers that were supplied by NTCSS program of record 
managed by PMW-150. These IT assets were included in the overall Navy/Marine Corps 
NMCI program, which merged the Marine Corps aviation IT requirements into the 
overall program. The APOC was conducted for multiple issues related to the services 
contracted by NMCI. Marine aviation had delayed transition into NMCI when it was 
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observed that the transition process interrupted IT services. Marine aviation is dependent 
on IT services to provide functionality to its NTCSS aviation software applications, 
which are required to enable Marine aviation units to maintain operational readiness. 

Marine aviation had a great stake in ensuring the transition of Marine aviation 
NTCSS was functional and supportable in the NMCI environment. The requirements for 
the transition and operation of Marine aviation NTCSS systems determined by the APOC 
TIWG to ensure the transition of Marine aviation into NMCI would enable Marine 
aviation to maintain operational readiness during a time when aircraft readiness was 
essential. Members of the APOC TIWG also had the goal of creating the template for 
transitioning all of Marine aviation into NMCI in order to meet contractual agreements. 

The APOC TIWG was formed with the stakeholders who were involved in every 
aspect of Marine aviation IT maintenance support. The APOC TIWG worked diligently 
to identify operational requirements and potential setbacks in the Marine aviation 
transition into NMCI. The APOC DT identified the potential issues and a project plan 
was put into place to reduce the risk of those issues. The result of addressing these issues 
and standardizing the solutions not only brought Marine Corps aviation closer to standard 
NTCSS applications amongst all of the Marine Corps aviation units but also helped 
standardized the commonality between the Marine Corps and Naval aviation NTCSS 
applications. 

The APOC OT proved that Marine Corps aviation could function on the NMCI 
network without any interruption of services, particularly the NTCSS suite of aviation 
maintenance applications. The standardization of Marine Corps aviation maintenance 
applications was a tremendous step forward in making the Marine aviation transition to 
NMCI a success. This also reduced the workload of trying to keep several obsolete 
software applications in the DADMS database. The APOC TIWG had brought the risk 
of the main issues of the APOC DT down to an acceptable level or provided a temporary 
alternative solution for the OT to be executed. The APOC provided a framework for 
Marine aviation and NMCI to transition all of Marine aviation over to NMCI. 
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B. MARINE AVIATION TRANSITION ISSUES INTO NMCI 


The issues identified during the APOC DT have either been resolved or a 
temporary solution put in plaee. The four issues help ensured a smooth transition of 
Marine aviation assets into NMCI and set the stage for standardization. 

I. Marine Aviation Seat Transition 

The APOC DT identified several issues and proeesses to whether Marine aviation 
was eapable of transitioning and operating on the NMCI network without diminishing 
operational readiness. These issues were addressed by the APOC TIWG to mitigate the 
risk to acceptable levels in order to proceed with the APOC OT and the eventual 
transition of all Marine Corps aviation into NMCI. The seat transition was the basis of 
all NMCI transitions of Navy and Marine Corps sites/bases. The ED process sought to 
identify what IT assets and services were present at these sites/bases and configure them 
to meet the SLAs of the NMCI contract. 

A large percentage of the IT assets operated by Marine aviation units were from 
the NTCSS program of record and thus had a higher accountability than other Marine 
Corps units. HQMC Aviation made the decision that all Marine aviation flying 
squadrons would have 90 computers. The number of computers each MAES unit was 
determined on the number of personnel in the unit and how many squadrons the MAES 
supported. This was necessary in order to place the orders in NET and start the transition 
process. The next issue was to map software applications to the individual seat. This is 
where the APOC started to answer what the requirements were for Marine aviation for 
NMCI. 


a. Aviation Applications 

The Marine aviation maintenance applications template created for the 
APOC OT proved to be the basic template to be used throughout the Marine aviation 
transition. The standard NTCSS applications used by all Marine aviation units were the 
initial forty-two NTCSS applications identified after the aviation pre-assessment in 
January 2005. The Marine Corps aviation template was used to configure the computers 
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used for the APOC. The template enabled CTRs to plaee orders for software applieations 
with one eliek viee having the customer choose what software applications they required. 

The basic template had to be expanded upon when the NMCI transition 
went to other Marine Corps bases/sites. Each base/site could only LADRA test the 
software applications that were used on that base/site’s COT Thus, all of the aviation 
maintenance software applications that dealt with a specific aircraft type would only be 
available at those base/sites that tenanted that particular aircraft. For example, the rotor 
and balance software program for the AH-IW helicopter would only be available sites 
such as Camp Pendleton’s MCAF, MCAS New River, and NAS Atlanta, where AH-IW 
helicopters were stationed. Thus, CTRs created an aviation template for their respective 
bases/sites, which would have all of the Marine Corps NTCSS applications on the COI 
for that base/site. 

b. NTCSS Printers 

The NTCSS printer solution was one that was more of a contracting issue 
than of technology. The issue identified in the DT found that the NTCSS print servers 
could not print to the NMCI printers. The other issue was the quantity of printers 
allowed for a Marine Corps aviation unit. After years of negotiating, the issue finally 
found a solution. 

The solution was to allow Marine aviation units to connect their NTCSS 
printers to the NMCI network at no charge. The stipulation was that there would be a 
one-time connection at no charge for when the unit transitioned to NMCI. The Marine 
aviation units that had already transitioned were simply allowed to continue as they 
already had the NTCSS printers connected to the legacy network. 

2. DP-17 Van Pad 

The DP-17 van pad initially presented itself as the easiest problem to resolve. 
While this was true technology, it was not true in getting the agreement signed by all the 
stakeholders involved. The initial agreement to connect the Marine Corps aviation DP- 
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17 van pads was never signed by NMCI offieials. Although the DP-17 was not an 
official agreement, it was used during the Marine Corps aviation transition. 

3. X-COI 

The X-COl issue was solved with Navy and Marine Corps aviation units that 
require network connectivity. The Marine Corps DAA allowed the necessary portals to 
be opened to either the MATS unit or Navy AIMD that provided the aviation logistic 
support for that base/station. A formal solution was finally drafted and acted upon. 
USMC-5000-2007-3941 was an addendum to the Cross COl solution to provide required 
services not previously addressed by the STEAG. This allowed Marine aviation users to 
utilize naval aviation resources and vice versa, support NALCOMIS and Marine aviation 
units, and support requirements to host Marine aviation seats on the Navy NMCI COl. 



Figure 23. Proposed USMC Cross COl Solution^o 


Figure 23 taken from General Topic Update Brief to FIQMC, C4. September 2007. 
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The stipulations of the X-COI agreement are as follows: 

• Creates a one-way trust between USMC NMCI and USN NMCI (upon DAA 
approvals) 

- USMC users may log into USN NMCI seats 

- USMC users may aceess USN CLIN 27 servers (i.e., NALCOMIS) via 
Deployable Site Transport Boundary (DSTB) 

- Deployed users may reaeh back into the local Navy or USMC COI via 
DSTB 

• Provides option for a garrison version of the DSTB 

- Approx. 200 port switch 

- Intended to allow users to access Navy & USMC NMCI resources from the 
other enclave (upon ODAA approvals) 

- NALCOMIS users will be able to access Navy CLIN 27 servers & USMC e- 
mail, S drives, etc from the USMC NMCI enclave 

- VUSMC users will be able to use a Navy NMCI network to access USMC 
NMCI services 

The X-COI was one of the obstacles in making the NMCI network a true intranet. 
Many complaints were voiced when Navy and Marine Corps units located on the same 
base no longer used the same network, thus, they actually needed two networks on a base. 
Network security was and still is the major factor in the X-COI issue. 

4. Marine Aviation NTCSS Servers 

The transition of the Marine Corps NTCSS servers to NMCI was a successful 
project. The transition followed the execution discipline process and completed the 
Marine Corps NTCSS transition according to the project timeline. 

C. CURRENT STATUS AND NEXT GENERATION ENTERPRISE 
NETWORK 

The Navy’s Program Executive Office for Information Systems (PEO-IS) and 
HQMC C4, along with MCSC’s PM NMCI, have begun the requirements phase for re¬ 
competing the current NMCI contract. The follow-on Navy and Marine Corps network 
called the Next Generation Enterprise Network (NGEN) will replace NMCI. The goal of 
NGEN is to take NMCI to the next level. It will eliminate the negative features of NMCI 
and take the positive aspects of NMCI forward to form an intranet. 
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1. 


Current Status of Marine Aviation and NMCI 


The use of NMCI CLIN 4 AC Deployable computers is different depending on 
where the Marine organization is operating. Marine Forces Central Command has forbid 
the use of NMCI computers to Operation Iraqi Freedom (OIF) theater since 2007. West 
coast Marine aviation units still use NMCI deployable computers for shipboard 
deployments and while conducting military exercises. Many of the east coast aviation 
units have traded their NMCI laptop computers for NMCI desktop computers. HQMC 
C4 has purchased laptops for deployment use through the Marine Corps Hardware Suite 
(MCHS) program. The NMCI contract expires on 31 September 2010. Navy CIO 
Robert Carey predicts that it will take until 2012 to transition to NGEN. 

2. The Future of Marine Aviation and NGEN 

The use of an outside contract vendor will continue when the NGEN contract is 
awarded. The main difference is that not all IT assets will be controlled by the vendor. 
The government and/or military must retain control at certain levels in order to adapt to 
changing requirements and resources. Outsourcing IT services while in garrison has 
proved beneficial. However, the use of said same IT services has not proved successful 
for deployed Marine Corps forces with NMCI. The flexibility to adapt to joint and sister 
service networks was hampered by the use of NMCI deployable computers. The dismal 
logistical support provided by NMCI to deployed forces hampered IT readiness levels. 

D. FUTURE RESEARCH 

The APOC proved that NMCI and Marine aviation maintenance applications 
could function together. The other part of the APOC was to evaluate the logistical side of 
NMCI in support of NMCI Deployable computers. The APOC used the OT as the test 
bed to determine whether NMCI Deployable support was effective for Marine Corps 
units. The APOC was not a good determinant for the logistical support from NMCI 
because the base was still undergoing transition to NMCI. Also, the test was not accurate 
since it was influenced by the PEO-NMCI and NMCI executive bodies to conduct the test 
when the base was not ready to support NMCI Deployable computers logistically. The 
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NMCI Deployables Group conducted a Lean Six Sigma projeet after the APOC to 
identify the support required for a deployed unit. This included but was not limited to 
extra eomputers, software, and hard drives. Many other issues were improved in the 
NMCI Deployable support but it finally eame to HQMC C4 purehasing non-NMCI 
eomputer to support the deployed forees in global war on terror. Thus, Marine aviation 
NMCI eomputers were mostly left in garrison while units deployed. In would be 
benefieial to Marine aviation and the Marine Corps to determine what the requirements 
are for a deployed support paekage. The support for deployed Marine forees should be 
for two distinct phases. The first was for the initial incursion where follow on support 
was not available. An IT support paekage should be capable of supporting a designated 
unit for a set time period. The seeond phase would be after initial hostilities had ended 
and the logistieal ehain had been established. 

The other area of interest is how the Marine Corps aviation will funetion globally. 
Currently, units take their NTCSS servers or data and work from stand-alone systems that 
periodieally eonneet to the NTCSS network. As the NMCI eontraet will end in 2010, 
Marine aviation should develop requirements for IT support for the NTCSS network, to 
be used whether in garrison or deployed, without interruption of serviee. 
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APPENDICES 


A. SERVICE LEVEL AGREEMENTS 

SERVICE NAME: END-USER PROBLEM RESOLUTION 
SLA: lOI 

Performance Category: End User Problem Resolution 
Increment 1 SLAPC: 101 

SERVICE NAME: NETWORK PROBLEM RESOLUTION 
SLA: 102 

Performance Category: Network Problem Resolution 
Increment 1 SLAPC: 102 

SERVICE NAME: END-USER SERVICES 
SLA: 103 

Performance Category: E-mail Services - User E-mail Availability 
Increment! SLAPC: 103.1.1 

Performance Category: E-mail Services - E-Mail End-to-End (Client-Server-Server-Client 
Performance 

Increment! SLAPC: 103.1.! 

Performance Category: E-mail Services - E-Mail Server Service Availability 
Increment 1 SLAPC: 103.1.3 

Performance Category: E-mail Services - E-mail Client Responsiveness 
Increment! SLAPC: 103.1.4 

Performance Category: Web and Portal Services 
Increment! SLAPC: 103.! 

Performance Category: Pile Share Services - Server Availability 
Increment 1 SLAPC: 103.3.1 
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Performance Category: File Share Services - Client Responsiveness 
Increment 1 SLAPC: 103.3.2 

Performance Category: Print Services 
Increment 1 SLAPC: 103.4 

Performance Category: Network PKI Logon Services 
Increment 1 SLAPC: 103.5 

Performance Category: Problem Resolution for Access to Government Applications Increment 1 SLAPC: 
103.6 

Performance Category: HAS Services - Service Availability 
Increment 1 SLAPC: 103.7.1 

Performance Category: RAS Services - Client Responsiveness 
Increment 1 SLAPC: 103.7.2 

Performance Category: Blackberry Services 
Increment 1 SLAPC: 103.8 

SERVICE NAME: HELP DESK 
SLA: 104 

Performance Category: Average Speed of Answer - Telephone Calls 
Increment 1 SLAPC: 104.1.1 

Performance Category: Average Speed of Response - Voice Mail/E-mail 
Increment 2 SLAPC: 104.1.2 

Performance Category: Call Abandonment Rate 
Increment 1 SLAPC: 104.2 

Performance Category: First Call Resolution 
Increment 1 SLAPC: 104.3 
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SERVICE NAME: MOVE, ADD, CHANGE 
SLA: 105 

Performance Category: Move, Add, Change 
Increment 1 SLAPC: 105 

SERVICE NAME: INEORMATION ASSURANCE SERVICES 
SLA: 106 

Performance Category: Security Event Detection 
Increment 1 SLAPC: 106.1 

Performance Category: Security Event Reporting 
Increment 1 SLAPC: 106.2 
N00024-00-D-6000 
Conformed Contract POO 129 

Performance Category: Security Event Response 
Increment 1 SLAPC: 106.3 

Performance Category: Configuration Management 
Increment 1 SLAPC: 106.4 

SERVICE NAME: NMCI INTRANET 
SLA: 107 

Performance Category: Availability 
Increment 1 SLAPC: 107.1 

Performance Category: Latency/Packet Loss 
Increment 1 SLAPC: 107.2 

Performance Category: Voice and Video Quality of Service 
Increment 1 SLAPC: 107.3 
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B. USMC AVIATION MESSAGE 


From: ou:CMC WASHINGTON DC C4(uc) [c=US;a=DMS;o=VA12;cn=AL 
11397;oul=TVYX4;ou2=MLADCOC2;] 

Sent: Thursday, September 02, 2004 12:34 PM 

To: COMCABWEST(UC); AL 11398(UC); AL 11397(UC); COMCABEAST(UC) 
Co: CMC WASHINGTON DC C4 CP(UC); CMC WASHINGTON DC C4(UC) 
Subject: MARINE CORPS TACTICAE AVIATION NAVY MARINE CORPS 
INTRANET 

/(NMCI) TRANSITION M R 021600Z SEP 04 ou:CMC WASHINGTON DC C4(uc) 
UNCEAS 

COMMARCORBASESEANT 


Importance: Eow 


TO COMCABWEST(UC) 

AE 11398(UC) 

AE 11397(UC) 

COMCABEAST(UC) 

CC CMC WASHINGTON DC C4 CP(UC) 
CMC WASHINGTON DC C4(UC) 


UNCEASSIEIED// 

MSGID/GENADMIN/CMC WASHINGTON DC C4 CP// 

SUBJ/MARINE CORPS TACTICAE AVIATION NAVY MARINE CORPS 
INTRANET 

/(NMCI) TRANSITION MESSAGE 4// 

REE/A/MSG/CMC WASHINGTON DC C4/171924ZAUG2004// 

REE/B/MSG/CMC WASHINGTON DC C4/091400ZJUE2004// 

AMPN/REE A IS A JOINT C4/AVN ASE MESSAGE THAT PROVIDED GUIDANCE 
TO ASSIST GROUPS AND SQUADRONS IN ORDERING AND IMPEEMENTING 
AN NMCI SOEUTION AND INCEUDED MAG HEADQUARTERS, ACTIVE 
EEYING SQUADRONS, EOGISTICS SQUADRONS AND AVIATION MARINE 
CORPS CAEIBRATION ACTIVITIES ONEY. REE B IS THE NMCI Q3 BASEEINE 
SCHEDULE.// 

POC/GARANT PC/COL/HQMC AVN ASL/-/TEL:DSN 224-1835/TEL:COMM 
703-614-1835/EMAIL:GARANTPC@HQMC.USMC.MIL// 

POC/GLOVER RA/CIV/PM NMCI IT1/-/TEL:DSN 278-0709 
/TEL:COMM 703-784-0709/EMAIL:GLOVERRA@USMC.MIL// 

POC/HILTON PK/COL/C4 CIO/-/TEL:DSN 223-3490/TEL:COMM 703-693-3490 
/EMAIL:HILTONPK@HQMC.USMC.MIL// 
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GENTEXT/REMARKS/1. THIS MESSAGE PROVIDES ADDITIONAL GUIDANCE 
EOR MARINE AIRCRAET WING (MAW) AND MARINE CORPS AIR STATION 
(MCAS) UNITS THAT ARE PREPARING TO TRANSITION TO NMCI AND ARE 
NOT ADDRESSED IN REE A. 

2. MAW AND COMCAB/MCAS UNITS THAT ARE NOT "TACTICALLY 

ALIGNED" AND ARE LISTED BELOW, WILL CONTINUE WITH THE NMCI 
SEAT ROLLOUT PLAN AS DEVELOPED JOINTLY BY THE SITE TRANSITION- 
OEEICER-IN-CHARGE (STOIC) AND EDS TEAM (READ IN TWO COLUMNS) 
MAW MCAS 

HQ MAW HHS 

MACG VMR 

MTACS 

MASS 

MWCS 

MACS 

LAAD BN 

VMU 

MWSG 

MWSS 

3. MCSC WILL BE INEORMED ON ALL CORRESPONDENCE REGARDING 
EXECUTION AND VARIATIONS OE SEAT ROLLOUT. MAW G-6'S OR THEIR 
DESIGNATED REPRESENTATIVES WILL CONTINUE TO WORK WITH LOCAL 
STOIC AND CTR TO PLACE NMCI SEAT ORDERS WITHIN THE LIMITS OE 
CURRENTLY BUDGETED NMCI EUNDS AND EXECUTE BASELINE 
SCHEDULES IDENTIEIED IN REE B. 

4. TO EURTHER CLARIEY REE A, ALL MARINE AIRCRAET GROUPS WILL 
REMAIN IN EXTENDED AOR AND THE "AS-IS" NETWORK WILL NOT BE 
CHANGED UNTIL OTHERWISE DIRECTED. 

5. POLICY QUESTIONS CAN BE DIRECTED TO HQMC ASL/C4.// 
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c 


APOC TIWG CHARTER 



DEPARTMENT OF THE NAVY 

HEADQUARTERi UNITED STATES MAnNE CORPS 
2 NAW ANNEX 
WASHINGTON. OC 2«380-177S 


M HCPLr MPCA TQ; 

5000 

HQMC C4 
4 Jan 2005 


SUBJ: USMC NAVY MARINE CORPS INTRANET (NMCI) DEPLOYABLES TEAM 
CHARTER 

1. Purpose . To establish the USMC NMCI Test Intention Wort Groep (NMCI TIWG) intl its 
mission. 

2. CanccDation . None. 

3. BackEP?und 

a. The Marine Corps Oversight Council (MROC) has directed that efforts be maJc to address 
MAGTF NMCI deplo>able concerns with an einphas.s on aviation requiremenLs. Accordiogly. 
the NMCI TIWG was formed to derermine tiie eapability of eurient NMCI poiey and procedures 
to adequately support deployable MAGTF uniu in the following phases: 

1. ) Transition from garrison NMCI environment. 

2. ) Sustainmenl of deployed combat focused units. 

3. ) Transition to a deplo)cd status and feinteg*ate into the NMCI garrison environment. 

b. HQMC C4 and USMC PM NMCI will serve as co-chairs of this work group and actively 
drive this effort. Tl»e Marine Corps Operational Test and Evaluation Activity (MCOTEA) will 
serve as tbs assessment lead to include final coordination of the pa nninp . conduct and post- 
asscssmen. repvning. 

4. Mission . The NMCI TIWG will accomplish the following: 

a Interface with Director NMCI represertatives and Navy stakeholders, to include Space 
And Naval Warfare Command (SPAWARi and Commander Operational Test and 
Evaluation Force (COMOPTEVFOR), to suppiort the planning, conduct and reporting cf 
follow on test and evaluaiioa (FOT&E) of NMCI dcployablcs as they relate to the USMC. 
Every effort should be made to align USMC deployable concerns with the FOT&E 
process currently envisioned by the Director N.MCI. 

b. Plan, conduct and report on a "Proof of Concept” of NMCI deployables daring 4th Qir 
FY-OS as it specifically rcUtes to USMC aviation requiremenLs and concerns. Provide a 
report to HQMC C4 by 29 April 05 on findings, conclusions and lecomraendationN on the 
capability of USMC aviation to deploy iind letam to garrison in an NMCI environment 
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c. Plan, conduct and report on the ability of NMCI to support the deploying needs of a 
MAGTF. This assessment should include command, ground, aviation, and combat 
service support elements and the supporting establishment. Every effort should be made 
to align this assessment with the timetable for the assessment of FOT&E deployabics 
envisioned by Director NMCI to occur late FY05 or during FY06. Within 45 days of the 
conclusion of the FOT&E. MCOTEA will provide a quick look report to the MROC on 
their findings, conclusions and recommendations regarding NMCI and the MAGTF's 
ability to conduct requisite operations. 


5. Organization 

a. Chair; This will be shared by USMC PM NMCI and HQMC C4 

b. Assessment lead: MCOTEA 

c. Members: 

1) Marine Coips Systems Command (MCSC) 

2) HQMC, Command, Control, Communications and Computers (C4) 

3) HQMC Plans, Policies and Operations (PP&O) 

4) HQMC Installations and Logistics (I&L) 

5) Marine Corps Combat Development Command (MCCDC) 

6) Marine Corps Network and Security Command (MCNOSC) 

7) Marine Corps Operational Test and Evaluation activity (MCOTEA) 

8) Electronic Data Systems. INC. (EDS) 

- d. Ad Hoc Members: Representatives of the following organizations are encouraged to 
participate and will be provided access to relevant issues, discussions, and results for 
specific purposes. Representatives will be invited to participate when issues relevant to 
their organizations are addressed. 

1) Director NMCI 

2) Space and Naval Warfare Systems Command (SPAWAR) PMW*164 

3) Commander Operational Test Force (COTF) 

4) Marine Corps Tactical Systems Support Activity (MCTSSA) 

5) MAGTF Staff Training Program (MSTP) 

6) Training and Education Command (TECOM) 

7) Joint Interoperability Test Command (ifTC) 


6. Scope . As co-chairs. USMC PM NMCI and HQMC C4 will provide overall guidance and 
ensure all preparation for this effort is conducted in timely and productive process. When 
required, team members will assist MCOTEA’s efforts as needed in assessment planning, 
conduct and reporting. 
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7. Responsibilities 


a. USMC PM N\ICI — as TIWG co-chair and material developer, plan, coordinate and 
conduct all necessar> efforts to ensure all activities leading to the conduct of the Proof 
of Concept assessment and the FOT&E arc succcssflilly completed. This includes 
ensuring the availability of units and assets for successful completion of assessments. 

h. HQMC C4 - as TIWG co-chair and overall advocate, plan and coordinate efforts 
leading to a successful assessment of N.VICI. As advocate, be the final arbitrator of 
requirements. 

c. HQMC PP&O - act as advocate for ground forces that participate in the planned 
as.sessments. 

d. HQMC Aviation - act as advocate for aviation forces that participate in the planned 
as.sessments. 

e. HQMC li&L - act as advocate for combat service support forces and the supporting 
establishment that paniciputc in the planned assessments. 

f. MCNOSC - act on behalf of the Commanding Officer of MCNOSC to ensure MCEN 
issues are clearly identified and resolved or mitigated. 

g. MCOTEA - act on behalf of the Director MCOTEA and be the final arbitrator in the 
specific planning, conduct and post as.sessment reporting of the planned assessments. 

h. MCCDC - act as advocate for the Command Elcnrents that participate in the planned 

assessments. 

8. Effective Date . This charter is effective upon concurrence as indicated below. 


Dir C4 Date 

Qac '1. O^ Approved 

_ _Disapproved 

_ _Other:_ 


CG MCSC 


Date 


l 4 Wy g 


0^ Approved 

_Disapproved 

_Other:_ 



2T 0^ Approved 

_Disapproved 

_Other;_ 
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E 


USMC AVIATION APPLICATIONS TEMPLATE 



Application Long Name 

Application 

Acronym 

Version 

DADMS 

ID 

Navy RFS 
Number 

USMC 

RFS 

Number 

1 

Airborne Weapons 
Information System 

AWIS- 

AWARS 

Web 

454 

None 

None 

2 

Aircraft Engine 
Management System 

AEMS 

Web 

14931 

Several 

None 

3 

Aircraft Inventory 
Readiness and Reporting 
System 

AIRRS 

Web 

22795 

62116 

62116 

4 

AIRRS-NALCOMIS 
OOMA SCIR 


Web 

31093 

None 

None 

5 

Automated Weight & 
Balance System 

AWBS 

9.0 

8228 

85825 

85825 

6 

AV-8B Hover 

Performance Program 


1.2B 

29179 

68145 

68145 

7 

Aviation Maintenance and 
Supply Readiness Report 


3.0 

22639 

72791-CDA 

None 

8 

Aviation Maintenance 
Training Continuum 

System (AMTCS) 

Software Module (ASM) 

ASM 

2.0 

17386 

82335 

82335 

9 

Aviation Material 
Maintenance Management 

AV3M 

004- 

14.00.00 

15658 

62079 

62079 

10 

Aviation StoreKeeper 
Information Tracking 
Systsem 

ASKIT 

7.1.1 

31896 

88054 

85966- 

CDA 

11 

Broadened Arrangement 
of Resources from a Basic 
Accessory Relocation 
Application - Supply Issue 
and Recovery System 

2000 

BARBARA 

SIRS 

1.3.136 

30501 

81376 

81376 

12 

Central Technical 
Publications Library 

CTPL 

3.01a 

29180 


None 

13 

Electronic Maintenance 
System 

EMS2 

Viewer 

2.8.1.0 

34332 

88935 

88935 

14 

Individual Component 
Repairables List 

ICRL 

WEB 

7416 

Several 

None 

15 

Joint Air Logistics 
Information System 

JALIS 

2.0 

15540 

10418 

10418 

16 

Joint Aviation Technical 
Data Integration 

JATDI. 

REDSTONE.A 

RMY.MIL 

WEB 

15768 

62082 

62082 
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Application Long Name 

Application 

Acronym 

Version 

DADMS 

ID 

Navy RFS 
Number 

USMC 

RFS 

Number 

17 

Local Asset Management 
System 

EAMS 

4.0 

21767 

68127 

68127 

18 

Main Rotor Blade Track 
and Balance 


2.1 

27405 



19 

MEASURE Automated 
Information System - 
Personal Computer 

MEASURE 

AISPC 

4.3 

20734 

77885 

77885 

20 

MEASURE PC 
INVENTORY QUERY 

MEASURE 

INVENTORY 

QUERY 

W9808.3 

1 

10073 

85047 

85047 

21 

METPRO 

METPRO 

2.1 

22776 

78876 

78876 

22 

Module Test & Repair 

Suite 

MTR Suite 

3.5 




23 

NAECOMIS (EEGACY) 
ORGANIZATIONAE 
MAINTENANCE 
ACTIVITY 

NAECOMIS 

EEG OMA 

122- 

03.05.18 

21253 

10624 

10624 

24 

NAECOMIS component 
Sybase Open Client 


11.1.1 

27523 

89692 

89692 

25 

NAECOMIS Optimized 
Organizational 

Maintenance Activity 

NAECOMIS 

OOMA 

825- 

03.04.10 

(7) 

22727 

87778 

87778 

26 

NAVAE AVIATION 
EOGISTICS DATA 
ANAEYSIS 


Web 

441 



27 

NAVAE AVIATION 
MAINTENANCE 
DISCREPANCY 
REPORTING 

PROGRAM 


Web 

22606 



28 

NAVAE TACTICAE 
COMMAND SUPPORT 
SYSTEM II DESKTOP 

NTCSS II 
DESKTOP 

803- 

02.02.05 

23216 

89691 

89691 

29 

Navy Portable Flight 
Planning System 

N-PFPS 

3.2 

14740 

10699 

10699 

30 

NTCSS INTEGRATED 
BARCODE SYSTEM 

NTCSS IBS 

894- 

02.00.30 

22755 

10759 

10759 

31 

NTCSS NAECOMIS 

OPTIMIZED 

INTERMEDIATE 

MAINTENANCE 

ACTIVITY 

NTCSS 

NAECOMIS 

OIMA 

815- 

01.06.00 

23910 

87779 

87779 

32 

NTCSS Relational Supply 

I 

NTCSS 
RSUPPEY I 

822- 

01.01.65 

23909 

87777 

87777 
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Application Long Name 

Application 

Acronym 

Version 

DADMS 

ID 

Navy RFS 
Number 

USMC 

RFS 

Number 

33 

OPNAV AVIATION 

TRAINING 

MANAGEMENT 

SYSTEM 

OATMS 

8.0 

17156 

10423 

10423 

34 

RETAIE ORDNANCE 

EOGISTICS 

MANAGEMENT 

SYSTEM 

ROEMS 

9.0 

24475 

84574 

84574 

35 

SQUADRON 

ASSISTANCE/RISK 

ASSESSMENT 

SARA 

5.0.3 

33304 

90815 

93847 

36 

SUPPORT EQUIPMENT 
CONTROEEING 
AUTHORITIES TOOES 


4.1 

21785 



37 

SUPPORT EQUIPMENT 
RESOURCE 
MANAGEMENT 
INFORMATION 

SYSTEM / SUPPORT 

EQUIPMENT 

MANAGEMENT 

SYSTEM 


5 

21995 



38 

SURVIVAE 

EQUIPMENT ASSET 

TRACKING 

SYSTEM/INCREASED 

CAPABIEITIES 

PROGRAM 

SEATS/ICAPS 

4.0 

22942 

10282 

10282 

39 

T-AVB AUTOMATED 
EOAD PEANNING 
SYSTEM 

TAEPS 

2.8 

27597 

68370 

68370 

40 

Technical Publications 
Eibrary Program 

TPE 

3.0 

15839 

77657 

77657 

41 

VIB REVIEW 

VIB REVIEW 

2.2 

23068 

84446 

84446 

42 

Windows Standard 
Automated Eogistics Tool 
Set 

WINSAETS 

5.02 

8231 

10503 

10503 
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F. EDS/USMC MARINE AIR GROUPS 

Change History 

The following Change History Log eontains a reeord of changes made to this 
document. 


Date 

Published/ 

Revised 

Version 

No. 

Author 

Section/Description 
of Change 

03-Feb-2005 

1.0 

Springer 

DRAFT document sent to 

Jason Spezzano for review 
and input. 

07-Feb-2005 

1.1 

Jason Spezzano 

Filled in Template format 
with DRAFT agreement to 
begin staffing/routing 

process. 

30-0ct-2007 

2.0 

MGySgt 

Connie Wright 

Removed ambiguous 

statements and inserted 

NTCSS printer solution. 






The document version number identifies whether the 
document is a working copy, final, revision, or update, 
defined as follows: 


Final: The first definitive edition of the document. The final is always 
identified as Version 1.0. 

Revision: An edition with minor changes from the previous edition, 
defined as changes affecting less than one-third of the pages in the document. The 
version numbers for revisions 1.1 through 1.9, 2.1 through 2.9, and so forth. After nine 
revisions, any other changes to the document are considered an update. 

Update: An edition with major changes from the previous edition. 
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defined as ehanges affeeting more than one-third of the pages in the doeument. The 
version number for an update is always a whole number (Version 2.0, 3.0, 4.0, etc.). 


Ref (a): Revised Joint Survey Checklist 


a 

Ref (a) J oint Survey 
Checklist 

Ref (b): MAG Connectivity Template 


♦ A 


"Ref (b) MAG vl-1 
2002 Format.vsd" 

Ref (c): 4th MAW Aviation map 



Ref (c): 4th MAW 
Aviation Map 


Ref (d): USMC NALCOMIS Printer Agreement 


a 

Ref (d): USMC 
NALCOMIS Printer 

RELEVANT CONTRACT PROVISIONS : (Being reviewed for any 

applicability) 


[Insert relevant contract provisions] - Action (if required); 
Melanie Springer EDS contracts. 


[Write analysis] - Action (if required); Melanie Springer EDS 
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USMC DP-17 VAN PAD AGREEMENT 


Contracts 


FACTUAL BACKGROUND : (Will be applied to final format 
for historical perspective) 


AGREEMENTS / POSITION REGARDING rPescribel : 

SCOPE: THE INFORMATION BELOW APPLIES TO USMC AVIATION 
MOBILE FACILITIES. 

All of these agreements have been agreed to formally 
and resolve deployability and applications concerns with 
respect to MAG units (specifically Squadrons and MALs). 

The Joint Site Survey Checklist and the Connectivity 
Template are tools to assist sites in following the 
Execution Discipline Process Pre-DM 1 requirements. 


Layer 1 - Physical Layer (IMA) - (See IMA Diagram) 

• Government will provide single physical MAG Point of Presence (PoP) or 
eonneetivity to MAG mobile facilities. 

• NMCI will provide single physical MAG Service Point (distribution or aeeess 
switch). 

• Shared Infrastrueture from the MAG Point of Presence (PoP) to the wiring eloset 
(IDF, MDF). 

• Wiring Closet to the Van Pad is GFE/Govemment OOM (owned, operated, and 
maintained). 

• All eable in the Mobile Faeilities is GFE/Govemment OOM (owned, operated, and 
maintained). 
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• Connection from MAG Pop to wiring closet will be at least two pair of fiber as 
required. 

o (1) Lit, (1) Dark to be used for fail over. 

IMA Diagram 

(Shared infrastructure at times down to the VAN PAD - Survey dependent). 




= Bldg/Van Pad 


Layer 2 - Network Layer (IMA) 

• The following logical networks will be provided. 

o NMCI printer (1) VLAN 
o NMCI Seat (1 or more) VLANs, 
o MAG Servers & Printers VLAN. 

• Marine Aviation will provide additional ports as required to accommodate NMCI 
seats in vans. 
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Layer 3 - Routing Layer 

• Use existing USMC Base IPs. 

• When USMC deploys they will use deployed IP spaee. 

• If VANs move to another NMCI loeation, NMCI will provide IP spaee from 
Base IP alloeation. 

Cross COI Communications 


• Server-to-Server communication can work through VPNs. 

• Must be coordinated on a site-by-site basis. 

• Will require service DAAs to be in concurrence. 

• EDS needs to configure regional cross-COI VPN (today only one is between Quantico and 
Norfolk). 

- San Diego (SDNI) to San Diego (SDNZ). 

K’Bay (KBAZ) over legacy B1 to Pearl (PHRL). 

• Navy NALCOMIS needs to come from behind B2 and move into Navy NMCI. 

• (O’CONUS) Requirement for VPN? 

• 

BASE OPERATIONS 

• Base operations personnel will pick-up NMCI owned printers prior to units 
deploying. 

ASSUMPTIONS 


Connectivity Template encompasses IMA and OMA. You will see these inserted 
into the connectivity template 


• Network Management 

o Government will configure, manage, and monitor GFE that is part of the 
MAG. 

o Government will provide EDS SNMP read only community strings for 
monitoring. 

• VPN 

o Continue to use legacy VPNs for existing tunnels, until MCNOSC agrees to shut down of 
legacy B-l’s. 

o Shut down of legacy B-l’s will transfer VPN’s tunnels to NMCI B-Ts. 
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• SLAs 


(Specific SLAs are being outlined by EDS SLA team.) 

o GFE is outside scope of NMCI SLAs, but Workstation Break-fix SLAs apply. 

o Any SLA that relies on Government owned infrastructure does not apply 
(availability, performance). 

• lAVA Compliance in accordance with CLIN 0027 

AG: 

o USMC responsible for MAG network components (Program of Record), 
o LDS responsible for NMCI Seats and Printers. 

Item of Note: USMC Server and EDS Client lAVA updates require close 
coordination prior to Radia pushes. (I.E. NALCOMIS, Rsupply, Mid-Tier, JTDI, NLSA, 
and OOMA Updates). 
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G. MCAF KANEOHE BAY NMCI TRANSITION SCHEMATICS 
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MAG-24 DP-17 Van Pad Complex 
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